Dynamic typing

>string all data coming in
>????

What are you even trying to convey with this reply?

this

>>dynamic typing
>>>how data actually works
Amazing, the first thing you said was already wrong

>static typing hundreds of thousands of lines of backend

sounds like you think that static typing somehow adds workload. did you ever learn a modern statically typed language? hint: type inference

Nobody knows for sure; it was dynamically typed.

cast whatever type you want from string?

hehehehe

in real life dynamic stuff is hard to debug.

Please explain how one byte differs from another as seen from the level of a CPU. Are bools colored blue? Do chars smell like wood?

You legitimately have schizophrenia or something

Let me rephrase the question, as you seem to be either unable to understand it, or have to resort to childish name-calling to try and draw attention away from your obvious mistake:

OP's statement was that dynamic typing is how data actually works.

You said that this was wrong.

So, why is it wrong? How is data "strongly typed" on a fundamental level?

How does a number know if it's positive or negative?

Because we represent data with computers, and computers are fundamentall built on words/bytes. which are basically numbers. Every piece of data has to be formatted and stored numerically, you can't store the data abstractly like you implied. Fucking moron

Abstractly was the wrong word, I meant 'qualitatively'

It doesn't, that's the point.

In other words: the data is dynamically typed, as it's the program that determines what type a particular (set of) byte(s) is or represents. Thank you for acknowledging your mistake.

You're clearly out of your depth on this subject

You don't know why static typing was created. Get the fuck off Jow Forums

>It doesn't, that's the point.
Then how does it represent it on the screen? How is it possible that computers even work if they don't know what is positive or negative?

They don't have to know anything, all they have to do is follow instructions. The meaning (typing) of the data is itself part of the data. At its basis, it's just shuffling bytes around. A byte is a byte, that's all the computer know. There aren't separate registers or opcodes to handle ints, or chars, or pointers. Hence: the typing is dynamic.

Come now, I let you off with just showing how wrong you were, Best to scurry off now to shitpost in another thread about stuff you clearly know nothing about.

>n other words: the data is dynamically typed
no
its untyped

How is instructions and knowing no synonymous in your mind?
Bytes mean nothing, it's only when you have instructions to translate said bytes they have meaning behind them.
Bytes have flags, that tell CPU what that said byte do.

theres seperate opcodes for floats and ints

>bytes have flags
And here we are again. You think that bytes have some special flavour to them that lets the CPU know whether it's dealing with a particular data type. They don't. A byte of 8 bits does not have extra flag bits. Hence: dynamic/weak. Programming languages can impose their own restrictions on the data, but at its fundamental level, the data is dynamic.

>Hence: the typing is dynamic.
Your propositions are fine, but I don't agree that it leads to this conclusion. Different types take up different space in memory and have different encoding. Even in a dynamically typed language, the program keeps track of these encodings and will allocate memory appropriately, it's just handled by your interpreter or compiler instead of you.

No, there are separate opcodes for treating a sequence of bytes as a float or an int. There's nothing special about the bytes themselves, either in the registers or memory where they're kept. (Though such an architecture is certainly possible.)

You don't know what dynamic typing means
It means data has a type and it's checked at runtime
At the lowest level data has no type, that means it's untyped, not dynamically typed

Negative/positive int has a first bit as flag.
Maybe you shouldn't argue about this?

Types are useless abstractions.

OH look ITS THIS THREAD again

ERHhmm

>In a data structure:
The data part defines how to interpret the 1s and 0s while the structure
dictates how the data is grouped together.
>b-but my raw bytes
Thats the binary number system, not data. those are numbers, not data.

If I give a computer using signed one-complement the bits of a number in signed two-complement the data will be different on the two computers even though the mathematical binary number is the same.

Wrong. The bit isn't marked as "this bit marks this byte as being a negative or positive number", it's marked as "bit 1/8 of this byte". If the byte is used to hold a char, then that bit isn't a flag. At all times, the bit just carries data. The meaning of the data (the typing) is done at a higher level. Not at the fundamental level.

its done in the fucking circuits you inbred mongoloid

lol this. I find the ability to refactor code in an ide with a static typed language is the killer feature that's converted me.

I used to like dynamic typing because I could start coding without knowing where I was going to end up ( and often specs change so it's not your fault ) but being able to change your mind about how you're doing things and have everything update automatically after you've forgotten much of it means that's not a complete disaster.

so your argument is, "When OPcode performs AND command, it's just bytes being changed"?
That probably is dumbest shit, it's literally irrelevant what happens on that level, it's just Boolean math, it doesn't have types, dynamic or static at that level, just Boolean math.

dynamic typing was cool back when people didnt have powerful IDEs where you could regex and then replace every instance with something else

Boolean math is implemented on the hardware level you idiot. There are no Ps and Qs and negation signs flowing through there thats all in your head, its electrons.

Negative signs exist and being upheld by the hardware, when number goes into the Int pipeline it doesn't just flow throw as fast as it can, there are rules and flags set when, why and how said int needs to go though pipeline.

>declare integer in C
>uses 4 bytes, not wasting a bit, being able to represent exactly 4294967296 distinct numbers
>Easily fits in half a CPU register

>Declare a variable in python and assigning it an integer value
>It needs an ob_next, which is a pointer (8 byte) to the next head
>It needs an ob_prev which is another 8 byte
>it needs a refcount which is another 8 byte integer
>It needs a pointer to a struct _typeobject so python knows what type it actually is
>And lastly, it needs 4 bytes to represent the int value itself.
>Just kidding, because actually the entire language allocates on the heap, so you need 8 more bytes to hold a pointer to the struct itself.
>Doesn't fit in a CPU register at all, even the pointer just barely fits and can't be optimized anyway since it's on the heap

So 4 byte vs. 44 bytes, which seems closer to the machine for you?

Dynamic programming is a mistake. Almost all problems you brainlets have with static typing are fixed by type inference. All the cases where dynamic programming seems "more convenient" usually just lead to really hard to debug bugs where a static language could tell you at compile time what you're doing wrong.
In the very, very few instances where you actually want dynamic typing, you can easily make it

why do python objects all need next and prev links?

Because all variables exist in a linked list. Probably so they can be iterated through for garbage collecting etc.

If it changes type from Int to float.
needs to create float and delete int.

You can check if something is a string or an int in one line.

By the same logic we shouldn't give names to variables and functions

it doesnt do that in place?

what if your shit is in cache and CPU wants to use it next cycle?

how does that change anything?

Holy fuck you are dumb

so you have changed your int to float in RAM.
but in Cache it's still Int and goes into processing, returns changed value and overwrites float to int in memory.
Now you have wrong type and wrong number.

Don't listen to him, that's not the reason.

Actually, those two pointers are only there if you compile with Py_TRACE_REFS.

Turn on heavy reference debugging. This is major surgery. Every PyObject
grows two more pointers, to maintain a doubly-linked list of all live
heap-allocated objects. Most built-in type objects are not in this list,
as they're statically allocated. Starting in Python 2.3, if COUNT_ALLOCS
(see below) is also defined, a static type object T does appear in this
list if at least one object of type T has been created.

Note that because the fundamental PyObject layout changes, Python modules
compiled with Py_TRACE_REFS are incompatible with modules compiled without
it.

So yes, those 16 bytes actually disappear on normal cpython environments. Still 28 bytes vs 4. And still every addition or comparison compiles to some heavy function call that needs to deref the header, deref the type pointer, check which types both variables have and then select a proper comparison algorithm.
Meanwhile, in C, it just gets turned into a single instruction.

Dynamic typing is a mistake. You give up performance, you give up correctness and all you get is faster prototyping, which is completely pointless because prototyping is always the fast part of application development - fixing bugs is what's REALLY slow. And that's where static languages shine.

what the hell are you talking about? the cache is an opaque abstraction, it handles itself, if you change a value in RAM it can deal with that

Cache is RAM that is closer to your CPU, that is it. It usually checks if it needs to be moved away from L1 to L2 or L2 to L3 but it really doesn't have that much of direct communication to system RAM, that is whole point of cache, to be fast.

He's not. He's absolutely right.
An unsigned char and a signed char are not different in memory at all. There's nothing different about them. The only difference is that you look at different flags when comparing which is greater / smaller / greater or equal / smaller or equal.

You should be ashamed of yourself.

>actually transforming the data on access
>"how data actually works"
Any kind of weak or dynamic typing as well as automatic boxing is NOT how data actually works, the closest you get to how data actually works is reinterpret_cast but even then it can change alignment.

You confuse dynamic typing with typeless languages. Dynamic typing actually stores type information in the runtime and performs checks and casts according to the usage. It works like crap for anything but the built-in types and is shit idea in general, the only acceptable use of it is late binding of some objects, like C# does with its dynamic keyword..

no shit, you think destroying and creating a whole new object is faster?

>In the very, very few instances where you actually want dynamic typing, you can easily make it
This is very false, especially for C. Having to pass everything as a void * because the type system can't handle generic object. And then have to pass the type as a flag because you lack the introspection necessary to deduce the type.

The whole purpose of dynamic languages is simplicity and trusting the programmer to know better. The semantics of an object make it trivial to put anything into a list or dictionary. Duck typing makes it easy to call methods on an object without needing to import every interface it might need. And storing all of that state makes it easy to save the state of execution by serializing an entire object, writing it to a file, and then loading it later. You also can't do anything like decorators in C without really complicated macros or polluting your code with ifdefs everywhere.

With Python, any skilled programmer can write the same program in a fraction of the time it would take in C. If I need performance, I can rewrite that section in C once I know it works in python.

This isn't true at all.
This just proves you are a moron.

How would you change a file in cache?

who said anything about files?

don't nitpick words.

Sure samefag, sure

That's because C's type system is way too primitive to be considered "static typing". Languages like C++, C#, TypeScript, Kotlin or Rust can accurately keep the type of their arguments in even the most absurd circumstances with features like Templates/Generics, SFINAE etc.

And in those few circumstances where you can't you're usually fine with a variant type, a subtype and if nothing else works, you can just do what dynamic typing would do and create a class with a "type name / id" field and the value itself. Then there's only a tiny fraction of your program that's plagued by type uncertainty. You didn't give up on it ouright like you would have with a language that only supports dynamic.

/thread

OP: also, it's called type-checked, not typed.

what the fuck? I have no clue what you're talking about, and I'm not sure you do either

You are also mixing up dynamic typing and weak typing.
Dynamic typing means types are determined at run time, in contrast to Static typing where all types are determined before execution.
Weak typing means that types may be either freely coerced or ignored, Strong typing means every object has a concrete type which must be respected

Python is Dynamic and Strongly typed, you get errors if you use the wrong type
JS is Dyanmic and Weakly typed
C is Static and Weakly typed
Haskell is Static and Strongly typed

Clearly i made a mistake, you instead of talking about intent of the question hanged on a singular word.

It is statically typed, but only if you use a limited subset of the languages which doesn't pass void *.

>You didn't give up on it ouright like you would have with a language that only supports dynamic.
This is false. Python is strongly typed, everything has a type at runtime and type coercion is very limited (unlike JS). If a type mismatch occurs, python will throw a TypeError which you can catch and handle.

Weak typing still involves type conversions, it's like static_cast that the compiler automatically injects for you.

i raff

>If a type mismatch occurs, python will throw a TypeError which you can catch and handle
At runtime. If you're lucky, you catch that in your tests. Hehehehe...

I'm not being pedantic I genuinely have no clue what you're talking about

I fixed your image bro

Attached: 1551375765755 copy.png (600x833, 470K)

Are you saying you don't write tests? Python also supports static type identifiers so you can lint your code before writing it like in a static language.

>Python also supports static type identifiers so you can lint your code before writing it like in a static language.
Great! Then you end up with a statically typed languages with the runtime penalty of a dynamically typed language. What a deal!
If you already realize that type safety is a good thing to have, why not reap all the benefits static typing gives you?

No idea why dynamic is so popular. People say learn python, because among other things has dynamic typing, but fail to say that there's no real IDE, so you're basically fucked when you have to backtrack every single time when you are working on a large project.
Oh, I can use the X function here, does it take the input as a string or int? Param1, param2. Yeah, fuck dynamic typing.

Literally the only person in the entire thread to capture the entire point of dynamic typing.

Because then you pay the price of static typing. Like having to compile your program to verify all the types match. Which is fine when you are writing your junior year project which is a couple thousand lines, but becomes a huge burden as the project size increases. Your code is also inevitably more verbose since you have to explicitly state your types repeatedly.

You pay a potentially huge penalty in development speed in exchange for maybe a bit of performance and safety? The latter is also questionable since dynamic languages are usually use in contexts where your data might be dirty anyway, so a static system just isn't has helpful to begin with.

Why would you ever need to type check your Python code? Why don't you know what the type is when you're writing your code? Brainlets detected.

are you seriously saying static typing is worse the bigger your project gets
because it's literally the exact opposite

>Which is fine when you are writing your junior year project which is a couple thousand lines, but becomes a huge burden as the project size increases.
If you're actually using a dynamically typed language for a huge project, you'll get much, much, MUCH worse shit than just compilation time.
Type checking is something you should be doing even if it's not enforced.

Typelet python is good for junior year projects. Once you actually start adding documentation, you're literally including type information in there, just in an ugly, hard to maintain way.
And if you believe your code is self-documenting while still being dynamic typed, I'm really glad that I'll never work with you.

Eventually, you will become an adult and get a job. At that point, you will have to read other people's code and other people will read your code. And you will quickly see that not having type annotations makes code much, much harder to understand.

>type annotations
Type annotations aren't type checks user. You don't have to run the program to find out what the type is.

That depends heavily on the use case, the size of your team, and the resources available for making nightly builds. I do know from a microsoft exec that it does take them an entire day to compile windows.

You say this as if the object soup that you are trust into with most bizlangs is anymore helpful. Those languages even add dynamic features because they recognize it sometimes becomes impossibly complex to do what they want with static typing.
So unless your language has a type system as useful as Haskell, then I question the benefits.

>Works his way through 5 layers of nested inheritance to find out which method is being called
>Finds pajeet casted his data unsafely anyway

now you're equating static typing to large inheritance trees like they have something to do with each other when they don't

nah it doesnt, static typiing is universally better for large projects, slow complication is a C++ thing

>So unless your language has a type system as useful as Haskell, then I question the benefits.
Even fucking java has a good enough type system for it to be preferable to "anything goes" in any project bigger than fizzbuzz.
Unless you're working with utter giga pajeets who use reflection for trivial tasks - then even java turns into a python-typed java.

>Those languages even add dynamic features because they recognize it sometimes becomes impossibly complex to do what they want with static typing.
Rare edge cases
Excusing typeless massacres in a generic program by mentioning those edge cases is no better than excusing writing a high-level application in C for muh fast.

Foobar staticallyTypedChad(Foo f, Bar b);

/**
* @param System::Foo foo
* @param System::Bar bar
*
* @return System::Foobar
*/
function dynamicallyTypedVirgin(foo, bar);

And despite these huge fucking blocks of comments everywhere, collective years of programmatic manpower will still be thrown into an endless abyss of trying to figure out which incorrectly inferred variable is causing the program to crash.

assert type(foo) == Foo
assert type(bar) == Bar

Dynamic is faster to write, while static is faster to debug.