The most based and redpilled language. Prove me wrong

JS can be used to write backend code too.

They are not more or less "powerful" than a static language... honestly, who tells you such a bullshit? dynamic languages are more error prone because of their dynamic nature, that is not an advantage!

The same as anything in beautiful in a statically typed language. What's your problem with dynamic typing exactly? It's more convenient when what you're writing isn't safety critical. Are you a Cnile?

>more error prone
How can a language be error prone? It literally does what you tell it to do. If it throws errors it's because (You) the developer created the situation.

yes and it's shit, it's neither the fastest to run or fastest to type, js is a bloatware

True, but not failing because of a "training" wheel is still less failing. Any help with writing good code should be appreciated

const compose = (f, g) => x => f(g(x))
I'd say this is more powerful than a godawful type declaration or not being able to do it at all because your type system sucks. Only ML family languages get this right of the mainstream langs.

Not that guy but static languages require you to write a lot more code to do the same amount of work as a dynamic language. This is especially problematic if you're working on a platform with tight constraints.

>not the fastest
because every piece of code you write requires the fastest execution time possible with zero compromises.

$print = "print";
$print($print);

puked in my mouth, what the fuck are you doing?

>fastest to type

The typing speed is limited by the programmer.

the language has to be efficient and be a useful positive tool for humanity, not a bloatware

don't get me wrong, I like dynamic typing when I need to get shit done in a short time for personal use. But more often I get paid to write code, and this code needs to pass several quality gates and the amount of testing needed to pass them is a lot with JS...

>bloatware
Come back when your balls drop.

Exactly, you should pick a language that fits the quality requirements you have. What you should never do, however, is use a language with a static but crippled type system (such as Java).

I've found typing related errors to not be a serious problem on JS if you know what you're doing and have written in dynamically typed languages before. If you're writing a hobby project or a not-so-critical application, JS is fine.

Printing.

delusional; js complexifies the world for nothing. it needs to be abandoned as fast as possible to improve it.

>delusional
>Thinks js will ever be abandoned
Hmm

>JS programmer
>complete lack of reading comprehension
checks out.

Dynamic languages are for people who like to waste time writing shitty unit tests to cover some of a type system's guarantees without any of the other benefits. Refactoring weakly typed code is a fucking nightmare. You're basically trading a small amount of mental thought to consider your types upfront for long term low maintainability. It's a fucking awful trade for anything that isn't literally a few dozen line script.

If you write your code properly then you don't need a type system or a ton of tests.

Yeah okay you just never write typing bugs. Absolutely fucking delusional. Never make anything life critical, please.
And still, you lose comprehensive refactoring tools. I hope you never have to make changes later. Not using a good type system is the most penny wise, pound foolish thing you can do in software.

If you write shit code, it'll be shit no matter what kind of language you write it in. Using a strongly typed language won't make it any easier to maintain. In fact, it's the opposite because you'll have to write repetitive code that does the same operation for different datatypes.

>what are design patterns
>what are integration tests
>what are libraries
If you can't leverage these things to write safe code then maybe you should find a different career path.

Thing is, you can do both in JS if you really want to.

There are several frameworks that allow you to have types, from just using ES6 classes to Flow JS.

Wrong.

>If you write shit code, it'll be shit no matter what kind of language you write it in.
Go ahead and write everything in brainfuck then. After all, the ergonomics clearly don't matter since if you're good you're good, right?
We are human, humans make mistakes. Languages which facilitate correct design are easier to use in the long run. The best languages strongly encourage using the type system, but let you dip out if it's being burdensome. 95% of your code should use it.
>you'll have to write repetitive code that does the same operation for different datatypes.
Holy shit you have no idea what you're talking about.

>design patterns
Yes. A good type system is just first class support for the design pattern of typing. This design pattern is often (poorly) emulated in dynamic and weakly typed languages.
>integration tests
Too course to detect all your typing bugs. Have fun pooly implementing a type checker in fucking tests.
>libraries
Non sequitur.

Just use Typescript. It's pretty good and everyone with a brain is already using it because it turns out types are extremely valuable.

>libraries
>non-sequitor
because libraries have nothing to do with writing software in your world.

ok Jow Forums, you have one sentence to convince on why js is total garbage

Most cancerous piece of shit ever created.

DYOR.

The existence of and ability to create libraries has nothing to do with a language's type system. If your entire project is nothing but a long string of high level library calls, then the language might as well be one of those drag and drop tools used to teach normies about conditionals and loops. The language has become a glorified configuration tool for some gargantuan library. That's not most software.

>that's not software
That is exactly what software is.

>The existence of...[libraries]...has nothing to do with a languages type system
Didn't mention anything about JS's type system. If you can read I said you can use libraries as a tool in place of static typing. Leveraging dependencies that have been tested can improve the safety of a language. Bad libraries in any language create errors, good libraries can reduce them if used correctly.

It's only technically software. Like how Betty in finance's sixteen tab Excel document that calculates final bills at the end of each month is technically "software" that she "wrote". Yeah sure. Making pretty pictures with HTML is technically writing software, too.
But it's not what a software developer usually does. Software developers are engineers who solve novel problems. If you're doing nothing but stringing library calls together, you're a code monkey.
>libraries as a tool in place of static typing
You must be trolling.
>dependencies that have been tested
npm ERR! 404 'left-pad' is not in the npm registry.
>libraries can reduce them
Libraries are useful when you have a subproblem within your problem domain, and that subproblem is common between problem domains. In this case, someone may have written something which solves this subproblem.
If your entire problem domain has been solved, then what the hell are you doing?
The answer is code monkeying.

wrong

Attached: 1200px-Lua-logo-nolabel.svg.png (1200x1200, 72K)

"Jow Forums told me to hate anything that isn't C"

>not wanting to roll my own encryption
>use library instead
>also don't want to build my own http server
>use library instead
>also don't want to build my own json parser
And whats the result of all these choices? Working software that delivers web content. Try building a website that serves millions of people, or write a back end service to process millions of database records. Why wouldn't you use other people's tested and supported solutions.

Yes, those are useful, but I never write something that just strings all that together.
For example, I wrote an automated media transcoder and library as a shim between PVRs and online media players. Think Red5 but for VOD and with much more advanced handling of metadata and series of things. I used ffmpeg, sqlite, and so many more libraries, but probably less than 20% of my thousands of lines of code are library calls or prep for library calls, and that's including calls to the three standalone libraries I dragged out of the project because they were obvious subdomains of the core problem (one of which is the entire transcoding portion, which does far more than you might expect. ffmpeg is great, but not totally comprehensive).
Why is this? Why is so little of my code library calls? Because there's no library for the core problem: Being a foss, metadata rich, VOD media library management shim with a good API. Scanning the disk, finding changed media files, aggregating metadata, doing versioning on the data storage backend, displaying the library, in-progress conversions, items ready for deletion, providing a nice API which can tell you what's changed since the last call, integrating with popular PVRs, error handling like you cannot imagine, etc.
In this software, the concept of a "media item" is defined. It's quite simple, but used in many places. The type system guarantees nobody misunderstands what a media item is. It has exactly these properties, these properties are of these types. If I change what a media item is (it's happened, sometimes assumptions are wrong when building things), then the compiler will tell me exactly who misunderstands what a media item is. It's invaluable once a project has grown beyond your ability to comprehend all at once. Type systems are your friend. They give you strong guarantees for little cost. Good languages will let you bypass it when necessary. It's a tool, like a library, which grants a solution to a solved problem.

Type related bugs are exceedingly rare compared to the lowest hanging bug problems being memory and logic errors. Types for anything related to bug prevention is fantasy.

That doesn't mean good type system is useless but this argument that a good type system leads to less bugs is utter bullshit

>Go ahead and write everything in brainfuck then. After all, the ergonomics clearly don't matter since if you're good you're good, right?

Ah yes, the typical brainlet strawman argument.

>Holy shit you have no idea what you're talking about.

You're the one who's absolutely clueless. Maybe you'll get a job after graduate if you're lucky, kid.

Type related issues are huge problems for him obviously.

>Type related bugs are exceedingly rare
blog.acolyer.org/2017/09/19/to-type-or-not-to-type-quantifying-detectable-bugs-in-javascript/
>That doesn't mean good type system is useless
Very correct, even if using a static type checker didn't prevent an entire class of bugs (obviously false, gonna toss your linter too?) the absolute biggest benefits of a good type system are the ability to create FAR better tooling for refactoring and design time analysis of code sections.

I have a job doing software engineering, where if I fuck up some people might not have their emergency call relayed in a timely manner, and that wasn't a straw man. You were literally using No True Scotsman (if you're a REAL developer you don't write bugs!) and I called your bullshit. Deal with it, retard.

Attached: 20190714_001652.jpg (1707x560, 326K)

>if you're a REAL developer you don't write bugs!

I never said that, retard. You're one who's saying that, retard. Lol, how can you be a good software engineer if you don't even have good reading comprehension? I know why you're so mad. It's because you're the one's who's having problems so you're projecting your shit on everyone else. Face it, retard, not everyone's a dumb ass like you.

Glue code language, next

>If you write your code properly then you don't need a type system
>If you write shit code, it'll be shit no matter what kind of language you write it in.
Literally "just be good, lol what's the problem?". You're Dunning Krugering the fuck out of yourself here, sprinting with the goal posts, and dropping fallacies like mad trying to do damage control. I'm not going to fall for this incredible display of cope, or your personal attacks. I know full well what it takes to build a moderately sized, high reliability system because I've done it several times. I don't exactly know what you've built, but since this is a javashit thread and you were talking about stringing libraries together to make a fucking website, I'm guessing not much.

You don't even know what glue language means, do you?

Lol, I'm another poster, but you're too dumb to tell the difference. I won't reply to your pathetic ass anymore.

Okay fag. Your opinion is worthless and you refuse to accept the truth anyway.

>thinks event handling is programming

>thinks fizzbuzz is programming

Attached: d3d848ff-cdc7-46d1-8e39-c6dc6f3efe45.jpg (640x360, 176K)

>thinks making the shiny button squish when clicked is programming

>thinks programming is programming

>JS
>making the shiny button squish
Imagine being this clueless.
Imagine trying to make a point about something while being this much clueless.

>thinks scripting is programming

checkmate, fullstack

It would have been the holy grail: lisp with c-syntax, if it wasn't a bunch of hipster tards and their web 2.0 shit destroying the ecosystem with their cancerous frameworks.

You are free to ignore the frameworks and reinvent the wheel for everything.

That's why there are so many frameworks and JS went to shit.

Try
$print = print()
$lol = $print
print(this.lol)

No one's pointing a gun at your head and forcing you to use the frameworks.

Frameworks don't matter brainlet. I can do literally anything with a browser and console.

Not him but keep coping.

Seems fine to me
Func compose = (f, g) => x => f(g(x));
var MultiplyAdd = compose(x => (int)x + 5, x => (int)x * 5);
var AddMultiply = compose(x => (int)x * 5, x => (int)x + 5);
Console.WriteLine($"MultiplyAdd: {MultiplyAdd(10)}; AddMultiply: {AddMultiply(10)}");
// MultiplyAdd: 55; AddMultiply: 75

Not really. Firstly, the type signature is really cumbersome. Secondly, it seems to convert stuff to objects, then back and forth. So what you end up with is inefficient with primitives, and more importantly no more typesafe than the JS example above. Your f function could accept an int, but g function might return a String and it wouldn't get caught by the compiler.

C# might be able to handle the type parameters if you add more boilerplate to it, I'm not sure. But compare this to Haskell's actually type safe version (type declaration not mandatory):

compose :: (b -> c) -> (a -> b) -> a -> c
compose f g = \x -> f (g x)

multiplyAdd = compose (\x -> x + 5) (\x -> x * 5)

This is what static types look when done right. With anything less you'd be better off with dynamic typing.

Meant for

Couldn't you do something like

static T3 Compose(T1 x, Func func1, Func func2)
{
return func2(func1(x));
}

static void Main(string[] args)
{
var result = Compose(10, x => x + 5, y => y * 5);
Console.WriteLine(result); //75
}

bump

Why?

its cumbersome to use. Typescript code compiles to JS and if there is some error, you need to look into JS output files in 80% of cases. You got 2x as much work for "muh types" benefit

So this is only in the context of compiling to JS. The language itself is awesome. I don't thing Google/Microsoft will wait so long to make their browser working with TP.

This, this is bait.

Attached: bd378881501b62565f5096d5fc9d8371f620d6c1b017a4da5f40d98d01d4a9d8.jpg (400x593, 107K)

it's not lisp

> not using the computer to check syntactic fails, during compilation of TS code.

JS monkeys are fucking retarded. You do know as a human you make errors all the time right? The compiler will pick up far more errors ahead of time instead of you scratching your ass figuring out endless runtime issues?

Been utilising WASM via emscripten here. The fucker is that currently emscripten spits out a .js and a .wasm file, and that the .js file pulls in the .wasm file for execution.

I fucking hope they manage to trash the need for .js totally instead of this partial bullshit.

> JS is a fusion powered spaceship

>WASM binaries are too big.
incorrect. The wasm files produced from my emscripten builds are smaller in size compared to the purely .js files produced by emscripten from the same code.

No one is saying errors dont happen, it's just type ones are not a problem at all. Proper code coverage will be good enough to catch them and testing and reading library change logs before integrating them.

Errors that would have been caught by a type checker happen all the time in practice in dynamic languages.

Lmao, no they don't. I don't know what deluded world you retards live in but they dont happen. Errors happen when people dont have code coverage and then change shit blindly. You can argue a type system maybe catches a part of the refector problem, but it's still small potatoes to actual logic errors.

Please go jerk off to that bullshit, "muh code compiles so it jus werks," Haskell meme and fuck right off. Typescript's typesystem is bland as shit and purely optional

Because being dynamic is sometimes useful, but it shouldn't be the default.

Yes, they really do. I literally just did a PR on a Python repo because someone assumed a function always returned a dict and it didn't.

that's not prolog