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" code...in which the nuances between C#, scala, go, Rust, or Java would make much difference.
So to the point, I write in Java all day. Having a UI framework written in Java adds almost NO value to me. None of the patterns are the same. None of the libraries are the same. Few of the best practices are the same. The 2 types of programming are so alien, I don't see how much better life would be having a UI toolkit written in Java than Swift, for example.
I've heard the argument many times that it's better if your devs only have to know one language...so just do JavaScript because they UI people can then write the backend code...but I have never heard that from anyone who knows what they're doing. Most of those projects I have seen have failed in the long-run.
No other trade wants FEWER tools. Carpenters don't look at a drill and wonder "hmm, if I could attach a saw blade to one of those, I could only carry 1 tool to the job site." Carpenters pick the best tool for the job and use it. They don't even use miter saws for tiles. They focus on the quality and efficiency of their work and little else. They have no problems buying 10 different types of saws, mastering each and lugging them around in their van everywhere they go.
Why do people who write in JavaScript, a fundamentally poor language, think...how can I get this chaos, risk, and unpredictability...only in more tiers? Why use these languages well optimized for my needs with a much much longer history of solving problems like mine?...when I can start with a very young platform that takes a language designed to be an easy-to-learn quick fix for low-priority browser interaction, largely as an afterthought, and tries to make it a high-stakes server-side technology?
I can't imagine someone with a lot of experience working on professional apps that actually make money and have changed hands a few times or had contributors in many time zones thinking an untyped language is what they need. Writing a reliable backend designed to last for decades and many changes of hands is tough enough...why throw away type safety and make life harder?
JavaScript is a surprisingly elegant language... Stop pretending that it is [Java] and you'll have a much easier time.
Yeah, I never saw the surprising elegance (well, when compared to Java everything short of brainfuck seems elegant.) But what am I supposed to get, cause I sure as hell don't get whatever it is. And I want to understand why people I think are smart like it. All languages have callbacks/events/map-reduce, and those seem to be the only differences I really noticed. (I'm sure I noticed more
> JavaScript is a surprisingly elegant language... Stop pretending that it is [Java] and you'll have a much easier time.
Wow you say elegance but what you really mean is im lazy and prefer to type as little as possible even when my code becomes mush.
Nonsense. No carpenter, for example, wants a zillion specialized screwdrivers for every damn thing. I say put #2 Philips heads on as much stuff as possible. Who wants 20T heads on some things, those weird square security bits on other things, flat heads on other things, etc.? It's preposterous.
So you're saying every carpenter carries around 1 screwdriver? Your explanation there shows me you've never actually done much with carpentry or wood. The square drive is actually quite superior to the Philips head. It gives more force and control and is far less likely to strip it. Kreg and Spax standardized to support that for good reason. The rest I've seen use square or torx. Philips heads slip out of the fastener if you don't use them in a very precise way. Philips and flat heads are very imprec
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 doi
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]
> If the language matters,
THe language only matters when the attributes of the lang affect the tooling. Todays javascript tools especially in the areas of refactoring etc are a joke compared to statically typed languages like java.
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" code...in which the nuances between C#, scala, go, Rust, or Java would make much difference.
So to the point, I write in Java all day. Having a UI framework written in Java adds almost NO value to me. None of the patterns are the same. None of the libraries are the same. Few of the best practices are the same. The 2 types of programming are so alien, I don't see how much better life would be having a UI toolkit written in Java than Swift, for example.
I've heard the argument many times that it's better if your devs only have to know one language...so just do JavaScript because they UI people can then write the backend code...but I have never heard that from anyone who knows what they're doing. Most of those projects I have seen have failed in the long-run.
No other trade wants FEWER tools. Carpenters don't look at a drill and wonder "hmm, if I could attach a saw blade to one of those, I could only carry 1 tool to the job site." Carpenters pick the best tool for the job and use it. They don't even use miter saws for tiles. They focus on the quality and efficiency of their work and little else. They have no problems buying 10 different types of saws, mastering each and lugging them around in their van everywhere they go.
Why do people who write in JavaScript, a fundamentally poor language, think...how can I get this chaos, risk, and unpredictability...only in more tiers? Why use these languages well optimized for my needs with a much much longer history of solving problems like mine?...when I can start with a very young platform that takes a language designed to be an easy-to-learn quick fix for low-priority browser interaction, largely as an afterthought, and tries to make it a high-stakes server-side technology?
I can't imagine someone with a lot of experience working on professional apps that actually make money and have changed hands a few times or had contributors in many time zones thinking an untyped language is what they need. Writing a reliable backend designed to last for decades and many changes of hands is tough enough...why throw away type safety and make life harder?
Re: (Score:2)
Yeah, I never saw the surprising elegance (well, when compared to Java everything short of brainfuck seems elegant.) But what am I supposed to get, cause I sure as hell don't get whatever it is. And I want to understand why people I think are smart like it. All languages have callbacks/events/map-reduce, and those seem to be the only differences I really noticed. (I'm sure I noticed more
Re: (Score:2)
Wow you say elegance but what you really mean is im lazy and prefer to type as little as possible even when my code becomes mush.
Re: (Score:2)
JavaScript is a surprisingly elegant language.
No, it isn't.
Elegance is not needed, reliability is! (Score:2)
No other trade wants FEWER tools.
Nonsense. No carpenter, for example, wants a zillion specialized screwdrivers for every damn thing. I say put #2 Philips heads on as much stuff as possible. Who wants 20T heads on some things, those weird square security bits on other things, flat heads on other things, etc.? It's preposterous.
So you're saying every carpenter carries around 1 screwdriver? Your explanation there shows me you've never actually done much with carpentry or wood. The square drive is actually quite superior to the Philips head. It gives more force and control and is far less likely to strip it. Kreg and Spax standardized to support that for good reason. The rest I've seen use square or torx. Philips heads slip out of the fastener if you don't use them in a very precise way. Philips and flat heads are very imprec
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: (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 doi
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)
Re: (Score:2)
THe language only matters when the attributes of the lang affect the tooling. Todays javascript tools especially in the areas of refactoring etc are a joke compared to statically typed languages like java.
Re: (Score:2)