Discuss Scratch

ajskateboarder
Scratcher
1000+ posts

js or python

redspacecat wrote:

-ComplexNumbers- wrote:

Programming in JavaScript is living hell. Programming in Python is pretty nice.
I think both javascript and python are pretty good. I use both.
You thought
>>> [1, 2, 3, 4] in [[1, 2, 3, 4]]
True
>>> [1, 2, 3, 4] == [1, 2, 3, 4]
True
>>> # normal!
> [[1, 2, 3, 4]].includes([1, 2, 3, 4])
< false
> [1, 2, 3, 4] === [1, 2, 3, 4]
< false
> // whar??
BigNate469
Scratcher
1000+ posts

js or python

-ComplexNumbers- wrote:

Programming in JavaScript is living hell. Programming in Python is pretty nice.
JavaScript isn't bad. It has really good cross-platform support, and is used on the web. Also, it's C-based.
ajskateboarder
Scratcher
1000+ posts

js or python

BigNate469 wrote:

-ComplexNumbers- wrote:

Programming in JavaScript is living hell. Programming in Python is pretty nice.
JavaScript isn't bad. It has really good cross-platform support, and is used on the web. Also, it's C-based.
Python is also C-based and supports C FFIs
BigNate469
Scratcher
1000+ posts

js or python

ajskateboarder wrote:

>>> [1, 2, 3, 4] in [[1, 2, 3, 4]]
True
>>> [1, 2, 3, 4] == [1, 2, 3, 4]
True
>>> # normal!
> [[1, 2, 3, 4]].includes([1, 2, 3, 4])
< false
> [1, 2, 3, 4] === [1, 2, 3, 4]
< false
> // whar??
In JavaScript you have to iterate through the array manually. Python does the same, just you don't have to write the code yourself.
mybearworld
Scratcher
1000+ posts

js or python

I'd argue JS's behavior makes more sense in this case. Compare:
>>> a = [[1,2,3,4]]
>>> b = [1,2,3,4]
>>> b in a
True
>>> b.append(5)
>>> b in a
False
>>> # so b isn't _actually_ in a!
>>> 
>>> c = [b]
>>> b in c
True
>>> b.append(6)
>>> b in c
True
>>> # but b actually _is_ in c.
>>> # however, before appending `b in a` and `b in c` are the same.
> let a = [[1,2,3,4]]
undefined
> let b = [1,2,3,4]
undefined
> a.includes(b)
false
> b.push(5)
5
> a.includes(b)
false
> // b isn't in a, and we know that from the beginning
undefined
>
> let c = [b]
undefined
> c.includes(b)
true
> b.push(6)
6
> c.includes(b)
true
> // and b _is_ in c, which we also know from the beginning
undefined
TheSecondGilbert
Scratcher
100+ posts

js or python

mybearworld wrote:

I'd argue JS's behavior makes more sense in this case. Compare:
>>> a = [[1,2,3,4]]
>>> b = [1,2,3,4]
>>> b in a
True
>>> b.append(5)
>>> b in a
False
>>> # so b isn't _actually_ in a!
>>> 
>>> c = [b]
>>> b in c
True
>>> b.append(6)
>>> b in c
True
>>> # but b actually _is_ in c.
>>> # however, before appending `b in a` and `b in c` are the same.
> let a = [[1,2,3,4]]
undefined
> let b = [1,2,3,4]
undefined
> a.includes(b)
false
> b.push(5)
5
> a.includes(b)
false
> // b isn't in a, and we know that from the beginning
undefined
>
> let c = [b]
undefined
> c.includes(b)
true
> b.push(6)
6
> c.includes(b)
true
> // and b _is_ in c, which we also know from the beginning
undefined
This is a thing because JavaScript doesn't compare the contents of an Array.
> [1, 2, 3, 4] == [1, 2, 3, 4]
false
Both may have the same content, but they are stored in different places, which is different enough for JS to call them not equal.
In contrast, Python does check for the contents of the list:
>>> [1, 2, 3, 4] == [1, 2, 3, 4]
True
IMO the Python way of checking equality makes more sense, since for something that stores multiple things, checking if the contents are the same makes more sense than if they are two different things stored in two different places. If you want to do the same thing in JS, you had to iterate them, or even recursively if there's arrays within them as well.

Last edited by TheSecondGilbert (March 24, 2024 11:07:29)

ajskateboarder
Scratcher
1000+ posts

js or python

BigNate469 wrote:

ajskateboarder wrote:

>>> [1, 2, 3, 4] in [[1, 2, 3, 4]]
True
>>> [1, 2, 3, 4] == [1, 2, 3, 4]
True
>>> # normal!
> [[1, 2, 3, 4]].includes([1, 2, 3, 4])
< false
> [1, 2, 3, 4] === [1, 2, 3, 4]
< false
> // whar??
In JavaScript you have to iterate through the array manually. Python does the same, just you don't have to write the code yourself.
Yes, I'm pretty sure JavaScript compares arrays by reference, so using === and .includes() doesn't work as a result. This is an ugly throwback to how Java comparisons work, except JavaScript doesn't even provide an .equals() method for arrays, so you have to use .every(). And to make matters even worse, according to freeCodeCamp, primitive data types are compared by value, while non-primitive data types are compared by reference. This means arrays are created as instances of Array. I guess the “Java” in JavaScript really means something doesn't it? Who uses identity hashcodes unironically anyways? (outside of comparing identities obviously)

Why can't arrays just be a primitive, as well as a reference datatype (like in Rust)? Also like how you can use numbers as-is or as Number instances (as if you should even instantiate numbers using CLASSES rrgh)

Also on an unrelated note: semicolons. Either force people to use them or don't - enforcing a middle ground like this can lead to somewhat confusing syntax errors. Here's an example that tripped me up a lot: (yes it's SIMPLIFIED i know all of it can be OPTIMIZED, replace the example with some document.querySelector call perhaps)

I can write all this without semicolons? nice
console.log("some log statement which I like")
console.log(1)
console.log(2)
console.log(3)
console.log(4)
Let's go use a .forEach loop
console.log("some log statement which I like")
[1, 2, 3, 4].forEach(ele => {
  // ...
})
index.js:2
[1, 2, 3, 4].forEach(ele => {
^

TypeError: Cannot read properties of undefined (reading '4')
Huh. Well I wanted this in an IIFE anyways. Like to avoid naming collision or whatever IIFEs are meant for :P
console.log("some log statement which I like")
(
    [1, 2, 3, 4].forEach(ele => {
      // ...
    })
)()
index.js:2
([1, 2, 3, 4].forEach(ele => {
^

TypeError: console.log(...) is not a function
These errors are very poor and misleading, and no, I shouldn't have to add in a whole formatter to fix everything. Just make the language consistent with semicolons requirements from the start

Last edited by ajskateboarder (April 4, 2024 00:40:52)

Mryellowdoggy
Scratcher
1000+ posts

js or python

Python is much simpler to use and can be used almost anywhere. And it has better backend functionality and extensive libraries. JavaScript is pretty good too though.
AHypnoman
Scratcher
1000+ posts

js or python

Mryellowdoggy wrote:

Python is much simpler to use and can be used almost anywhere. And it has better backend functionality and extensive libraries. JavaScript is pretty good too though.
Biased as JS is my first language, but:

Python can't be used everywhere - you need to install an interpreter. JS runs in every single browser.

Going by PIP and NPM alone, JS has >10x the number of libraries that Python has. That's excluding web libraries like React and Svelt.

As for backend functionality, Node, the most used backend JS runtime, has built-in functionality for HTTPS site serving (and other schemes). This is similar to python, putting them about equivalent here. I'd put Python higher here for large servers because of it's simple thread system.

I certainly wouldn't call python simple to use - it has the weirdest syntax of any mainstream language (excluding COBOL) I've seen: it's like having a conversation with a computer rather than giving it instructions (you have to write out or, and, not(?), etc.) and if you want to insert a new block around preexisting code you need to indent everything inside the block.

Another of my problems with Python is the fact that I can't lay code out nicely in the way I want - I must conform to Guido Van Rossum's design whims.

Also why do generator functions throw an exception when they finish?

Paragraphs are overrated.

Last edited by AHypnoman (April 2, 2024 22:06:22)

AHypnoman
Scratcher
1000+ posts

js or python

ajskateboarder wrote:

redspacecat wrote:

-ComplexNumbers- wrote:

Programming in JavaScript is living hell. Programming in Python is pretty nice.
I think both javascript and python are pretty good. I use both.
You thought
>>> [1, 2, 3, 4] in [[1, 2, 3, 4]]
True
>>> [1, 2, 3, 4] == [1, 2, 3, 4]
True
>>> # normal!
> [[1, 2, 3, 4]].includes([1, 2, 3, 4])
< false
> [1, 2, 3, 4] === [1, 2, 3, 4]
< false
> // whar??
This is actually really useful if you look deeper than simple comparisons: this lets objects (which arrays are) to be self referencing allowing for 2-way references between objects without a need for infinite memory.

Simple example of coupled arrays:
let a1 = []
let a2 = [a1]
a1.push(a2)
console.log(a1)
> [a2>[a1>[a2>etc]]]

Python:
#help me I am weak

Another advantage is that you can modify arguments without returning (which is normally insane practice but has some legitimate uses)

Edit: This apparently works on Python too - my mistake. Odd to have such an inconsistency though.

Last edited by AHypnoman (April 3, 2024 20:36:36)

Maximouse
Scratcher
1000+ posts

js or python

AHypnoman wrote:

This is actually really useful if you look deeper than simple comparisons: this lets objects (which arrays are) to be self referencing allowing for 2-way references between objects without a need for infinite memory.

Simple example of coupled arrays:
let a1 = []
let a2 = [a1]
a1.push(a2)
console.log(a1)
> [a2>[a1>[a2>etc]]]

Python:
#help me I am weak
This works in Python too. All Python variables are references.
a = []
b = [a]
a.append(b)
print(a) # output: [[[...]]]

Last edited by Maximouse (April 3, 2024 19:46:30)

mybearworld
Scratcher
1000+ posts

js or python

Maximouse wrote:

(#573)
This works in Python too. All Python variables are references.
Yep, so in Python, `[] == []` being true is a lie. `[] == []` being false in JS makes more sense.

Last edited by mybearworld (April 3, 2024 19:59:48)

Maximouse
Scratcher
1000+ posts

js or python

AHypnoman wrote:

Another advantage is that you can modify arguments without returning (which is normally insane practice but has some legitimate uses)
def append_1(l):
    l += [1]
a = []
append_1(a)
print(a) # [1]
BigNate469
Scratcher
1000+ posts

js or python

mybearworld wrote:

Maximouse wrote:

(#573)
This works in Python too. All Python variables are references.
Yep, so in Python, ` == ` being true is a lie. ` == ` being false in JS makes more sense.
Agreed.
Maximouse
Scratcher
1000+ posts

js or python

mybearworld wrote:

Maximouse wrote:

(#573)
This works in Python too. All Python variables are references.
Yep, so in Python, `[] == []` being true is a lie. `[] == []` being false in JS makes more sense.
Python's == operator compares values, but there's also the identity operator “is” which only returns true if both operands are the same object.
mybearworld
Scratcher
1000+ posts

js or python

Maximouse wrote:

(#577)
Python's == operator compares values, but there's also the identity operator “is” which only returns true if both operands are the same object.
Ah, fair, I forgot about `is`. That does act more sensibly in this regard.
AHypnoman
Scratcher
1000+ posts

js or python

Maximouse wrote:

~Snip~
My mistake (I'm not deeply familiar with Python), although given all python vars are references then why does this happen?
>>> x = "hi"
... y = "hi"
>>> id(x)
4414027184
>>> id(y)
4414027184
>>> def z(a):
...     a += "hhhh"
... z(x)
... x
'hi'
This means that strings are immutable while lists and dictionaries are mutable, but they're both passed in as refs. A string is a reference, but mostly acts as a primitive?

Also creating two separate strings assigns them the same reference if they are equivalent meaning that == and ‘is’ comparisons return the same, meaning that for almost every purpose a string acts as a js-like primitive, but isn't.

Last edited by AHypnoman (April 3, 2024 21:11:30)

ajskateboarder
Scratcher
1000+ posts

js or python

AHypnoman wrote:

Maximouse wrote:

~Snip~
My mistake (I'm not deeply familiar with Python), although given all python vars are references then why does this happen?
>>> x = "hi"
... y = "hi"
>>> id(x)
4414027184
>>> id(y)
4414027184
>>> def z(a):
...     a += "hhhh"
... z(x)
... x
'hi'
This means that strings are immutable while lists and dictionaries are mutable, but they're both passed in as refs. A string is a reference, but mostly acts as a primitive?
FYI,
a += "hhhh"
# shorthand for a = a + "hhhh"
does not mutate the variable, it just reassigns the value of a. Oh by the way, JavaScript also acts the same way
let a = "a"
function addhhhh(b) {
    b += "hhhh"
}
addhhhh(a)
console.log(a) // a
And Java while we're at it
class Main {
    public static void addhhhh(String b) {
        b += "hhhh";
    }    
    public static void main(String[] args) {
        String a = "a";
        addhhhh(a);
        System.out.println(a); // a
    }
}

AHypnoman wrote:

Also creating two separate strings assigns them the same reference if they are equivalent meaning that == and ‘is’ comparisons return the same, meaning that for almost every purpose a string acts as a js-like primitive, but isn't.
That's most likely for optimization purposes - when would you need to compare memory locations for two equivalent strings anyways?
imfh
Scratcher
1000+ posts

js or python

Some more weirdness with string references. Notice how the id changes whenever you modify it. This shows that a new string is being made behind the scenes, even if you use the += operator.

>>> a = "hi"                                                                                         
>>> id(a)
139918267500592                                                                                      
>>> a += " there"
>>> id(a)                                                                                            
139918269043632
>>> b = "hello"                                                                                      
>>> id(b)
139918269051248                                                                                      
>>> id("hello")
139918269051248
davidtheplatform
Scratcher
500+ posts

js or python

ajskateboarder wrote:

AHypnoman wrote:

Maximouse wrote:

~Snip~
My mistake (I'm not deeply familiar with Python), although given all python vars are references then why does this happen?
>>> x = "hi"
... y = "hi"
>>> id(x)
4414027184
>>> id(y)
4414027184
>>> def z(a):
...     a += "hhhh"
... z(x)
... x
'hi'
This means that strings are immutable while lists and dictionaries are mutable, but they're both passed in as refs. A string is a reference, but mostly acts as a primitive?
FYI,
a += "hhhh"
# shorthand for a = a + "hhhh"
does not mutate the variable, it just reassigns the value of a. Oh by the way, JavaScript also acts the same way
let a = "a"
function addhhhh(b) {
    b += "hhhh"
}
addhhhh(a)
console.log(a) // a
And Java while we're at it
class Main {
    public static void addhhhh(String b) {
        b += "hhhh";
    }    
    public static void main(String[] args) {
        String a = "a";
        addhhhh(a);
        System.out.println(a); // a
    }
}

AHypnoman wrote:

Also creating two separate strings assigns them the same reference if they are equivalent meaning that == and ‘is’ comparisons return the same, meaning that for almost every purpose a string acts as a js-like primitive, but isn't.
That's most likely for optimization purposes - when would you need to compare memory locations for two equivalent strings anyways?
This also applies to small integers, anything less than 256 IIRC.

Powered by DjangoBB