["10","10","10"].map(parseInt)

>["10","10","10"].map(parseInt)
[10, NaN, 2]
>["10", "10", "10", "10"].map(parseInt);
[10, NaN, 2, 3]
>["10", "10", "10", "11"].map(parseInt);
[10, NaN, 2, 4]
>["10", "11", "12", "13"].map(parseInt);
[10, NaN, 1, 1]

Attached: visibleconfusuin.jpg (480x270, 32K)

Other urls found in this thread:

developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt#Description
lispworks.com/documentation/HyperSpec/Body/t_satisf.htm
twitter.com/NSFWRedditGif

["10", "11", "12"].map(numString => parseInt(numString));

yeah python is a shitshow

>doesn't know that map sends 3 parameters to the callback
>parseInt(string, radix);
This is the result of dangerous assumptions.

>["10","10","10"].map(Number)
[10, 10, 10]

Attached: vivaldi_2018-08-22_21-40-35.png (457x479, 356K)

This

I was trying something similar on Thursday with .map(string.indexOf) but it was error'ing out. Realised it was because of this exact reason quite quickly

Not a problem in Julia:

julia> parse.(Int, ["10", "10", "10"])
3-element Array{Int64,1}:
10
10
10


Future is here, start your transition. Python is favored only for being ancient. This trend will change as more people start trying this much-better alternative.

Sure, you'll need to know Python to work with your teammates, etc. I also do. I'm just saying Julia is better and Python is shit, whenever I see the opportunity, to accelerate the mass-switch away from the Python garbage.

it's javascript you absolute specimen

That's not python you prick.

Parse int takes in an optional second argument, which defaults to 0 (interpreted as base 10), you dumb shit. Namely the base.

map() invokes the function with the first argument being the member, the second argument being the index.

CL-USER> (mapcar #'parse-integer '("10" "10" "10"))
(10 10 10)
CL-USER> (mapcar #'parse-integer '("10" "10" "10" "10"))
(10 10 10 10)
CL-USER> (mapcar #'parse-integer '("10" "10" "10" "11"))
(10 10 10 11)
CL-USER> (mapcar #'parse-integer '("10" "11" "12" "13"))
(10 11 12 13)

This

This

i don't get it whats .map

It creates a copy of the array and transforms each element using the provided function

hashmap? Which is like a dictionary?

i think they talked about that in my intro to java data structure course, i ended up failing that assignment so no wonder why i did not remember it

That's so dumb, why does it do that?

No I was guessing, listen to

what the actual fuck? anyone could explain how is this possible?

Attached: wtf.png (561x79, 8K)

Attached: 1539631179460.png (1024x295, 63K)

so what?

js is retarded

Attached: 1537458516961.png (856x488, 62K)

>That's so dumb, why does it do that?
Which part of it?
Why parseInt takes a radix argument? Because not all numbers are presented in base-10.
Why map() invokes the function with three arguments? Because in real-life scenarios that aren't fizzbuzz-tier, knowing the index and the array you're working on is actually useful.

See parseInt has a default argument, parseFloat does not.

>not using .map((...args) => args)

Function.prototype.cutoff = function (argc) {
var ref = this;

return function () {
return ref.apply(this, [].slice.call(arguments, 0, argc));
};
};

["10", "12", "13", "14"].map(parseInt.cutoff(1))

>does not default to 10
What does it default to?

developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt#Description

turns out it's not js retarded but we

Quite easy in the land of Raku:

('10', '11', '12', '13').map(*.Int)

# Or with a parallelizable map
('10', '11', '12', '13')>>.Int


However, as other user mentioned, this is probably an erroneous assumption, OP. Make sure to read the documentation to avoid things like this. After all, JS is a little bit weird.

nope, js is actually retarded.

what's that syntax?

raku is perl6

>not reading the documentation
>not knowing the language core functions and making assumptions about them
>"b-b-b-but I'm not retarded you guys, the language is"
zoomers need to lrn2 rtfm

go back to downloading an npm package just to determine if a number is odd

>the language core functions
It's not a core function)

kek

It's part of array's prototype, it can't get any more core than that.

let i = 2;
console.log(i % 2 ? 'even' : 'odd')

oh fucking cringe
console.log(i % 2 ? 'odd' : 'even')

very impressive

I don't need to know signatures, it should not even compile on a decent strongly-typed developer-time-efficient language

>decent strongly-typed
>developer-time-efficient
What an oxymoron

>t strongly-typed
well it passes number, so even strongly-typed language could make that error

A decent strongly typed language would be a closed system and not one that accepts user input, as it is inherently impure.

fuck off haskell shit
even common lisp has you beat
lispworks.com/documentation/HyperSpec/Body/t_satisf.htm

See I should not need to know signatures and specifications.

>lispworks.com/documentation/HyperSpec/Body/t_satisf.htm

i wonder who uses lisp these days? (apart from Lain fans and Emacs users)

i should not need to know anything
doesn't really matter, they're both memelangs
at least lisp went to space once

so why it didn't throw any exceptions

because it was doing what it was programmed to do

the fuck

let sum = (a, b) => a + b;
sum(2, 3);

HURR WHY DOES IT ADD 2 and 3 and not throw an exception I obviously want it to add 3 and 4

Was meant for

I think he was more commenting on the unused arguments that aren't clearly captured by the function's declaration. But JS code artisans know about spread and the infamous arguments array and that by nature all js function calls are variadic.

wow javascript a shit

I know, right? A programming language that doesn't give me a compiler error when I mistyped the numbers and pass the wrong integers as function arguments is clearly dogshit.

CL-USER> (defun sum (a b)
(declare (type (integer 3 4) a b))
(+ a b))
SUM
CL-USER> (sum 3 4)
7
CL-USER> (sum 2 3)
; Evaluation aborted on #.

That's why I always define numbers as literal constants, ONE, TWO, THREE and so on. It's easy to mistype a single digit, much harder to mistype an entire word.

["10", "11", "12"].map(x => +x)

wow javascript a shit

parseInt doesn't do what it looks like it does

look up the documentation, second argument is the numeric base

lmao
imagine programming in this nonsensical language everyday
>inb4 "it makes perfect sense user you just have to memorize the entire ECMA spec, that way you won't be surprised by things that would otherwise just werk in any other language :^)"

Attached: gab.jpg (457x652, 36K)

>implying you don't have to look up the arguments for mbsrtowcs

user, you're admitting to be too retarded for javascript. That's embarassing, please stop.

Attached: 1539489453352.png (400x297, 93K)

>uses X without knowing how X works
>"hurr X is such garbage, it doesn't work properly!!"

>php 5 is shit and here's why
>"I guess you're too retarded for php 5 user"
except that's not how it works sweaty

Only people too retarded for functional programming and understanding that JS mainly takes functions as arguments (i.e. lambda expressions) are confused by this.

See

JS: Built by retards, for retards.

>javascript is retarded
>"it's retarded on purpose tho"
k

What's exactly retarded by taking a base/radix argument?
Or do you mean passing the index of the current position as the second argument to the map callback? What's retarded about that?

This. The only people who think JavaScript is good are the ones who don't expect programming languages to have any sort of consistency anyway.
This is why JavaScript is very popular as a first programming language: you're less likely to notice that it is complete garbage if you never programmed in a real language.

I use Typescript everyday, and while I don't think it's a great language it's certainly better (more flexible, less verbose, less busywork) than OOP languages like Java. Go right now is too strict outside systems programming and Python is just retarded (>whitespace). Most deficits where straightened out by ES6, but you haven't kept up with that apparently.

So no, you can't tell me it's not the best for high-level tasks.

It's not the best for high-level tasks.

>whitespace
Yeah, because anything that forces everyone on the team to conform to the same code standard is obviously a bad thing.

A more traditional way of writing
('10', '11', '12', '13').map(*.Int)


would be
('10', '11', '12', '13').map({.Int})


which uses an explicit block with the topic variable.

As for
('10', '11', '12', '13')>>.Int


it's equivalent to writing
('10', '11', '12','13').hyper.map({.Int})

>more flexible, less verbose, less busywork
You mean slower, less consistent, more bug prone. Java is verbose because it follows consistent rules and doesn't allow beginners to break them just for the sake of convenience and not understanding the value of a language following logical rules.
And even if you think that Java is unnecessarily verbose, the improvement over Java is Kotlin, not JavaScript. Java, C#, Kotlin, Python, Swift are all examples of well-designed, high-level programming languages with varying levels of verbosity. JavaScript is not, even after years of work trying to fix it with ES201X, TypeScript, Dart, etc. it is still garbage and retarded by design.

Attached: 1564248064513.jpg (1024x576, 59K)

I understand where you're coming from but isn't using whitespace as a block delimiter a matter of design rather than a coding style? After all, one could argue that languages that use curly braces for delimitong blocks are forcing teams to conform to the same code standard and thus, as good as using whitespace.

i've got you covered homie
(loop for x from -999999999999999999999999999999999999999999999999999999999999999999
to 999999999999999999999999999999999999999999999999999999999999999999
do (multiple-value-bind (symbol)
(intern (substitute #\_ #\Space (string-upcase (format nil "~R" x))))
(setf (symbol-value symbol) x)))
CL-USER> ONE
1
CL-USER> TWO
2
CL-USER> THREE
3
CL-USER> TEN
10
CL-USER> ONE_THOUSAND
1000
CL-USER> NEGATIVE_TEN_THOUSAND
-10000

I honestly think that arguing against FOIC is a bad argument, because any company or team or project is going to follow some sort of coding style or standard anyway, and it's not like you're not indenting your blocks to begin with. In other words, I believe that if someone's main issue with Python is forced indentation, then they don't really have a solid technical reason for not using it.

To answer your question, my personal opinion is that it really doesn't matter if you're using curly braces or begin end statements or simply white space to delimiting blocks, what matters is how readable your code is.

Nice

It's always sad that people post this shit and think "JS is bad" but really it shows they don't have a basic understanding of pointfree programming, so they probably also can't write any FP code at all.

I'm still waiting for an answer for these, what exactly is retarded here?

no. u.

stay mad scriptlet

>Python

Typical Jow Forums poster. Knows neither python nor JavaScript, yet is opinionated about both.

akshually its ecmascript
>absolute state of Jow Forums

Static typed languages are for brainlets who need their compiler to hold their hand.

His whole post was the only retarded thing.

>missing the point
Typical Jow Forums poster

>thinking static and strong typing are the same
Nice projection, brainlet

>thinking there are compiled dynamically strongly typed languages

>Future is here, start your transition.
Fuck off, tranny.

Fucking based. This is the white man's language.

You wouldn't map a car

Idiot lmao

>setInterval that gets cleared by onclick.
>Other onclick sets new interval based stored var
>speeds up if clicked too fast
>can decrement past if statement for 0
JavaScript is a wonderful beast

good bait