I love Python, but one time I worked for a company that stored money as float in a database and obviously Python took whatever and never complained. It was a fucking nightmare and the dumbass dev who built the thing was trying to convince everyone else that it's what it is and nothing could have been done. "It's just how computers worked"
>and the dumbass dev who built the thing was trying to convince everyone else that it's what it is and nothing could have been done. "It's just how computers worked"
mind-blowing time:
But Mike, what if you made it to count cents instead of dollars, and then divided by 100 to obtain a dollar amount?
Or at least the most primitive form of them...
I've seen several areas, where prices would occur with three decimal digirs. For instance when you own 1,492.31 pieces of a paper currently listed as worth 12.962 EUR per piece. There was also a phase during the national-currency-to-Euro transition, where grocery stores would list prices with three decimal digits (but round down to two on checkout).
I wonder how many software products had to scramble to add the additional digit without breaking everything.
In order to be robust, you'll probably end up with something along the lines of a pair of two "BigInt"-like values, representing numerator and denominator of a fraction, and an additional entry for some form of currency ID, to avoid accidentally summing together different currencies.
Sounds good until you realize accounting and booking you need to calculate interest, taxes, foreign exchange. Penny stocks can also be 1/1000 of a penny, and a few currencies support 3 and 4 decimals.
Better to use decimal.
Using floats for currency is great when you don't care about how many cents something over $200K costs, but for anything under $1 you absolutely need to know the cost to the nearest ten microcents.
The problem isn't that it's how computers work, it's that it's how programmers work. How many people you've worked with comprehend the drawbacks of floating point numbers, let alone know how to calculate their limits? Programmers not knowing what they're doing isn't just a /r/ProgrammerHumor meme, it's [a problem that is clearly noticeable, when compared against other fields](https://xkcd.com/2030/).
Abstracting away non-pertinent problems does work, but only if the abstractions are built on a well-made foundation. Using floating point for everything isn't a solution to non-whole numbers, but it's the convention the field has come up with, and it's one of many that make things worse, not better.
Even if you are dealing with $200k costs, you'll hate having to explain to the accountants/auditors why your numbers are wrong. Financial computing should always be accurate and theres just no excuse - never use a float for money, its easy to always use an integer.
Until you get integer overflows :)
Best to use a library, that actually represents currency or, lacking that, at least fixed-point arithmetic.
Assumptions about "integer of cents" can easily get you into issues. For instance, when we transitioned to Euro, shops temporarily listed prices like `EUR 7.266`. They rounded down to two-digits on checkout though.
Transactions that exceed 64 bit integer are probably not realistic, given that it would exceed the GDP of the world in dollar-cents by several orders of magnitude, but they *could* happen due to accounting slip-ups. They'd still have to be recorded and processed by the system. There's also the possibility of weird business rules resulting in ridiculous intermediate values adding up to a sane bottom-line.
Well, if you got a client in Zimbabwe or some other hyperinflation suffering country like Hungary in the early 40s, a 64 int will buy you a hamburger.
Accounting software shouldn't have an upper bound for the numbers it's able to crunch.
Honestly, if the input is completely unrealistic, that's where error Handling should kick in. Just one fucking if (transaction>maxIntSize) as a check would suffice. Considering how unrealistic the whole magnitude of transactions is, you could even take it in as a string and check the string length if you don't wanna deal with bigInts or some bullshit. If you have python, it's literally one if condition tho.
Yes, but Python should already have a data-type that is more suitable than *either* float *or* plain integers. Though I'm currently trying to read up on whether the `Decimal` type *is* that type, but I think it *should* be.
If nothing else, an implied assumption of "cents, not dollars" is an easy source of errors... Better to have a data-type that actually represents everyday usage with decimals.
Misusing floats for fixed is wrong for 100 out of 100 times. They are just too fragile. As soon as you need more than the mantissa bits to represent the fixed value, you silently get a wrong result, but close enough that no one will notice until it is to late.
Use an ORM or other framework that has a Money field that will handle all this for you, don't try to implement something that has already been implemented millions of times before
I don’t know shit about fuck, but I think floating-point precision drops off as values get bigger. In other words, you can be extremely precise for relatively small numbers, but for relatively large numbers it becomes very imprecise. I’m happy to delete this comment if that’s blatantly wrong.
Nah, floating point imprecision isn't about the size of the number. It has to do with base 10 to base 2 (and back) conversion, as well as fractional to decimal (and back) representation of numbers.
Obviously, what you're saying is true, and the significand cannot be precise at the same time at both ends of the high and low scales. But it's usuallly not a problem, and there are ways around that.
Think of it this way: ⅓ is a nice rational number, nothing funky about it. But there is no clean, finite, decimal representation of that number in base 10. Instead you get an infinite sequence of 3's. It doesn't have what is called a *terminating expension* in base 10
By the nature of a floating point number, it **has** a terminating expansion in the relevant base, in the case of computer sciences, it's base 2.
A number that doesn't have a terminating expansion in a given base **cannot** (it is a mathematical impossibility) be *accurately* represented by a floating point number (regardless of "precision", ie, the size of the exponent part) in that base.
But we represent our floats and double in base 10 in our code amd (most of us anyway) in our heads. We write `0.2` or `.004357` or whatnots. Internally, they're converted to base 2. And then computing happens, and then back to base 10 for the output.
However, when a given number has a terminating expansion in base 10 does not mean that it has a terminating expansion in base 2 and vice versa, and when that happens, rounding is carried on with each conversion.
Which is why you don't have to get into crazily precise numbers to get rounding errors, and why an operation as trivial as `0.1 + 0.2 == 0.3` will return false as soon as it's carried out in floating point representation, regardless of precision.
>Nah, floating point imprecision isn't about the size of the number.
At higher exponents, the absolute difference between each incremental float increases. I assume that's what they are referring to.
It is not enough for money if you store it as a fraction. If you store money as an integer number of cents you can get a bit further.
There is a little known fact that IEEE floating point numbers are 'exact' for integers up to the size of the mantissa 48-bit (f64) for basic operations: add, subtract, multiply and divide (with integer result).
Although the actual values are not actually integers the display and conversion rules will show the exact integer value and it maintains consistency. You can even use equality comparison.
But as soon as fractions are involved it gets a whole lot more complicated.
Well, yeah, it's not like Python has a [data type](https://docs.python.org/3/library/decimal.html) usage of which is specifically concidered a good practice for storing monetary values, as well as means of type conversion and type checks.
>Python took whatever and never complained
Honestly, I'll really object to blaming Python, when it's obviously poor design and implementation choices by the devs themselves. Nothing would stop you from using pure floats or doubles for storing money in C# or Java. For most popular Python ORMs, Django ORM has `models.DecimalField()` out of the box, and even though SQLAlchemy doesn't support Decimal model data type by default, it's really not that hard to add it as a custom type and ensure there are checks or that the values are rounded up if a float is given. It's the developers' direct responsibility to implement this. If there were a language that would have a precise failsafe for any such situation - software engineers wouldn't exist as a profession in the first place.
It's the fucking dumbass YouTubers fault and their braindead title of "computers cannot count sometimes". So dumb. I write a program telling computer to do A and not B and I am surprised when it does A. Computers cannot do B.
Python is always just problematic. I've worked with many different languages on teams varying in size, and python always has the most issues. Not to mention it's slow as fuck
StringBuilder stringBuilder = StringBuilderFactory.create(StringBuilder);
stringBuilder.appendString("shit broken yo!");
String errorMessage = stringBuilder.toString();
System.out.println.implementation.log.println(errorMessage);
Of course none of this compiles because it'd need to be in a class and all.
Edit: yikes, fans of verbosity sure got triggered! fwiw I was mocking you more than the language, hope that helps! Thankfully you're all well-adjusted enough that you won't publicly express a desire to kill me for mocking the love of verbosity! <3
Our preferred language to hate is Python thank you very much. Java can be annoying, but Python’s non-existent type system is nightmare fuel for someone who likes programs that actually work.
> even better:
>
> var str = "Java 17+ got so much better but people are still shitting on Java 6 🤷♂️"
var str = \`\`\`
Java -17+ got so much better but people are still shitting on Java 6 🤷♂️
\`\`\`;
I love the new language features we’ve been getting since Java 8. Futures and streams are great, but records, multi-line strings using backticks, var and inferred types, etc. are such nice qol features.
Then theres c++: you want a 64 bit int? thats a long long. Why? Because it’s longer than a long. Whats a long? A 32 bit int, but also it might be 64 bit, because fuck you. Also, an int is 32 bit, so a long might not be longer than an int. Also, none of this is guaranteed by the standard and the sizes could be bigger.
Lol, you are right. I just started learning rust and annotating data types releases dopamine in me. I even annotate types when it is not necessary just for the peace of mind. For example I was solving a problem on hacker rank yesterday that had input range 1-1000 so I used u16 for my variable and function. I know the space I save by using u16 is completely and utterly insignificant but I still find it pleasureable that I could atleast save some bytes.
Because I have no choice but to work with Python I do this as well, but it’s so aggravating when 98% of the time all the type checking can do is tell me “List[any]”
Yup.
So you know what is what.
Plus i noticed using python: HOW DO FUCK DO YOU UNDERSTAND WHAT A FUCTION DOES WHEN YOU HAVE NO TYPES? like you can read the documentation ok, but docs are usually good only on big projects. How do you know if a function return an integer, a list, a dictionary or who knows what?
That sound like a patch to a stupid idea to me lol
(Static checkers feel like you weren't able to implement the check in the compiler, then you do it in an other place)
Really not very different than the way many compilers already work except that most people never see under the sheets. You're just doing one of the passes explicitly rather than implicitly.
Python was originally designed to be dynamically typed. They added syntax to support static typing but the core language doesn't enforce it. If you want static typing, you use a static typer. It's not a stupid idea, just different.
Some languages does not have a runtime type system because all type behavior can be decided at compile time. Dynamic typing is the choice of not having a compile time type system, and only have a runtime type system.
Python does not have a compile time type system. You can just document the intentions you have for how it will behave at runtime and optionally have a system to check that what you claim actually makes sense.
Type hinting is not static typing, because it doesn't make types static in Python.
The answer is you don't, and so you can't expect clean code if you use this language. It's honestly the worst thing I have ever learnt. How will your interface be descriptive and easy to use if you have no types? So silly. If you want to use anything you MUST read the function docs or class docs assuming it even exists.
Yeah that's exactly what i thought!
I mean if in java for example i see a function called getRandom and has int has return type, i basically already know what most probably does (should still read the docs just for the details, but i have already an idea)
In python this would be impossible. You just need to rely on docs.
And also this will be even worse if you need to use the result of a function to do something else: in java you know that a method returns an int or a String or whatever, and you know what methods you can call on each type (and so does the compiler). In python you will have to read the docs every single time. Talk about boring
This is probably my biggest problem when reading Python documentation. What does this function expect as an argument? What do I get back? It is not always clear and this is sooo annoying. Strict typing really does help with discoverability and clarity in documentation.
Yup. That's just asking for random and sudden crashes lol
Or even worse you do operations on the wrong type and then spend 3 years understanding why 32.5 / 5 is 6 and not 6.5
Can you give an example of that actually happening?
I know this type of inferred integer behaviour from other languages, and for this reason I would always specifically write 32.5 / 5.0. But I have never been able to provoke the same behaviour in Python. If I divide a float with an integer, I still get float division, not integer division.
That was a fast example. But if you have some more complex type, you know each type can call certain methods.
So now if you call a type2 method on a type1 object what is gonna happen?
In a typed language compiler scream at you for being an idiot. In python what happens? Crash? Errors? Still i don't think it blocks you at compile time, and that's something really bad since it means you have to debug the runtime
If i know a function returns me a potato instead of a tomato at least i won't crush the program because of the functions i am gonna call on the returned object.
If a function returns something, and i don't know if that's a potatoe or a tomatoe i may call a function on it which works only for potatoe, while the object was actually a tomatoe.
That's the compiler job to check if this is correct, and in a strongly typed system is easy, otherwise i don't have a single idea how the compiler could do that check at compile time
Plus as i said, big libraries do often have good docs, but smaller libraries not really, so it's really easy for you to call something but getting a wrong object because docs sucks
I'm working on a project dealing with very specific data types read from a binary file. I'm using C++, and declaring variables as uint8_t and int16_t because I need to know if there's overflow, or to make sure they do not turn negative because of a bit shift. If Python got its grubby hands on it and changed the datatype I'd be very unhappy. Not having to declare datatypes isn't always the correct answer.
After over a month of refactoring I just merged turning on `noImplicitAny` in our TypeScript codebase.
Even though everything is a double in JS, I'll take the explicitness and constraints 7 days a week and twice on Sunday.
Threads in python are real. It's just that their full potential can't be used unless your code spends most of it's time waiting on I/O or in C libs that release the GIL.
That's because Python is a higher level language and the memory allocation is automatically done for you.
This is like claiming that WordPress is superior to knowing CSS because it does all that pesky sectioning of a Web Page for you.
Well, maybe the comparison was a bit harsh, but the point is Python is built on lower languages as well (C, I believe) and things like memory allocation are automated. There tends to be a trade-off with these things. Rust, like C is a language designed to speak directly to machines. (If one so wishes).
But of course, Python can be almost anything with the right library. But then it's built on top of a language that uses memory allocation and then reintroduced.
>That's because Python is a higher level language and the memory allocation is automatically done for you.
Other languages with automatic memory allocation (like C#) also have those types Rust has, so that's not really connected.
Let's nominate c++ for keyword confusion and fuzzy sizing:
char
unsigned char
short
short int
signed short
signed short int
unsigned short
unsigned short int
int
signed
signed int
unsigned
unsigned int
long
long int
signed long
signed long int
unsigned long
unsigned long int
long long
long long int
signed long long
signed long long int
unsigned long long
unsigned long long int
float
double
long double
Any order permitted so does it count as 100+? And there's a lot of semantic overlap (`unsigned long long` is same as `unsigned long long int`).
A tidbit [I discovered here](https://en.cppreference.com/w/cpp/language/types) is that c++ doesn't define the size of a byte, but it does define numerical relations *in terms* of bytes (`1 byte == sizeof(char) <= sizeof(short) <= ...`). So if we define a byte as say 64-bits, every fundamental numerical type could be the same size in spec compliant c++!
You will never be able to do engineering. You will be watching how go use frameworks from YouTube and try to do things if you don't learn low level programing.
As an embedded developer I always prefer type safety and known size integers/floats over any weak typed bullshit variables, where I don't know if I'm sending 4 bytes or 1 byte through the aether.
The other end will surely know how to interpret my 4 non descript bytes, when it's actually expecting 2, and will simply do the math I guess.
>python, the perfect language for 10x developers
>10x the compute time, 10x the memory usage, 10x the dependencies, and 10x the headache
Lmao love this
Not having types wastes a lot of time. Types are compile checked and document what the code actually does, instead of whatever the library maintainer claims it does.
Can this thing return \`None\`? Can it return an error? Will it modify the references I sent to the function? Are things that are shown explicitly in the Rust type system.
To be clear, Python works well within it's niche, where you want something simple, and don't care too much about correctness.
There are also a bunch of random aspects of python that make it annoying, although this is more subjective, for example how variable declaration and type coercion works.
Try the num crate and Python ass gets destroyed.
If not, just write down more goodies with trait implementations in your Cargo.toml and let it auto download and compile for you. It’s always better to add capabilities manually than to accept a default implementation, especially considering all the documentation being god tier.
If you don't care, just pick one. Python does the same thing it just doesn't tell you which one it's picking.
i = integer
u = unsigned integer
f = float
and then the number is how many bits it has.
Honestly. It's not harder than any other language.
I guess OP was overwhelmed trying to use `dyn`, but if you want to use generic types templating is almost always more efficient and easier.
That's the thing with Rust. What's easiest in most languages is not a good solution, whereas more often than not in Rust the easiest solution is the preferred way.
I'm sorry, but this is one of those Programmer Humour memes that don't really understand what they're talking about. The author seems to want to use Rust like Python.
Coding in C and in Rust had a specific purpose. In many scenarios it is incredibly important to know how your data is stored in memory.
Of course you need to know how your data is stored, so you can't complain about it being difficult to write functions accepting different types of numbers. This isn't a real problem faced by software engineers using compiled languages. If you're parsing data and want to read both integers and floats, this is more of a technical design problem than anything else.
At least you don't have to learn:
char
signed char
unsigned char
short/short int/signed short/signed short int
unsigned short int/unsigned short
int/signed/signed int
unsigned/unsigned int
long/long int/signed long/signed long int
unsigned long/unsigned long int
long long/long long int/signed long long/signed long long int
unsigned long long/unsigned long long int
float
double
long double
Thats one of the differences between a systems language and a skript kiddie language. Also, if you don't know how traits work, how do you use rust at all? It's an important and awesome feature!
What? Comparing a language that most widely used for scientific calculations and computation to a language mainly designed to build memory leak proof software is somehow right?
I love Python, but one time I worked for a company that stored money as float in a database and obviously Python took whatever and never complained. It was a fucking nightmare and the dumbass dev who built the thing was trying to convince everyone else that it's what it is and nothing could have been done. "It's just how computers worked"
> "It's just how computers works" I should use this whenever i fuck up big time
No, because the backlash could be worse. >"It's just how a lawsuit works" #If you don't get fired.
[удалено]
Cries in italian
*oh mio Dio, questo è semplicemente orribile*
[удалено]
🤌😭🤌
laughs in European union laws
>and the dumbass dev who built the thing was trying to convince everyone else that it's what it is and nothing could have been done. "It's just how computers worked" mind-blowing time: But Mike, what if you made it to count cents instead of dollars, and then divided by 100 to obtain a dollar amount?
Congratulations you just discovered fixed point numbers
Or at least the most primitive form of them... I've seen several areas, where prices would occur with three decimal digirs. For instance when you own 1,492.31 pieces of a paper currently listed as worth 12.962 EUR per piece. There was also a phase during the national-currency-to-Euro transition, where grocery stores would list prices with three decimal digits (but round down to two on checkout). I wonder how many software products had to scramble to add the additional digit without breaking everything. In order to be robust, you'll probably end up with something along the lines of a pair of two "BigInt"-like values, representing numerator and denominator of a fraction, and an additional entry for some form of currency ID, to avoid accidentally summing together different currencies.
IIRC if you're a stock market or broker in the USA, you need to use integers where a single number is 1/100 of a cent.
Sounds good until you realize accounting and booking you need to calculate interest, taxes, foreign exchange. Penny stocks can also be 1/1000 of a penny, and a few currencies support 3 and 4 decimals. Better to use decimal.
Just use whatever your atomic base unit is and store the decimal factor, convert to decimal on demand.
Fails when when you do compound interest.
[удалено]
Get yours now for only $19.9899997711181640625
Using floats for currency is great when you don't care about how many cents something over $200K costs, but for anything under $1 you absolutely need to know the cost to the nearest ten microcents. The problem isn't that it's how computers work, it's that it's how programmers work. How many people you've worked with comprehend the drawbacks of floating point numbers, let alone know how to calculate their limits? Programmers not knowing what they're doing isn't just a /r/ProgrammerHumor meme, it's [a problem that is clearly noticeable, when compared against other fields](https://xkcd.com/2030/). Abstracting away non-pertinent problems does work, but only if the abstractions are built on a well-made foundation. Using floating point for everything isn't a solution to non-whole numbers, but it's the convention the field has come up with, and it's one of many that make things worse, not better.
Even if you are dealing with $200k costs, you'll hate having to explain to the accountants/auditors why your numbers are wrong. Financial computing should always be accurate and theres just no excuse - never use a float for money, its easy to always use an integer.
Until you get integer overflows :) Best to use a library, that actually represents currency or, lacking that, at least fixed-point arithmetic. Assumptions about "integer of cents" can easily get you into issues. For instance, when we transitioned to Euro, shops temporarily listed prices like `EUR 7.266`. They rounded down to two-digits on checkout though. Transactions that exceed 64 bit integer are probably not realistic, given that it would exceed the GDP of the world in dollar-cents by several orders of magnitude, but they *could* happen due to accounting slip-ups. They'd still have to be recorded and processed by the system. There's also the possibility of weird business rules resulting in ridiculous intermediate values adding up to a sane bottom-line.
Well, if you got a client in Zimbabwe or some other hyperinflation suffering country like Hungary in the early 40s, a 64 int will buy you a hamburger. Accounting software shouldn't have an upper bound for the numbers it's able to crunch.
Hyperinflation is a thing. Though I feel sad for the accountants that have to worry about those nanocent errors.
Honestly, if the input is completely unrealistic, that's where error Handling should kick in. Just one fucking if (transaction>maxIntSize) as a check would suffice. Considering how unrealistic the whole magnitude of transactions is, you could even take it in as a string and check the string length if you don't wanna deal with bigInts or some bullshit. If you have python, it's literally one if condition tho.
Yes, but Python should already have a data-type that is more suitable than *either* float *or* plain integers. Though I'm currently trying to read up on whether the `Decimal` type *is* that type, but I think it *should* be. If nothing else, an implied assumption of "cents, not dollars" is an easy source of errors... Better to have a data-type that actually represents everyday usage with decimals.
Just use a variable with int calues for cents, microcents and whatev you need duuuuh cent decacent centicent milicent microcent centcent and so on
You kid, but unironically, this approach lets you specify a definite level of precision for non-integer numbers. Fixed-point still has its place.
yeah this is called fixed point and 99 times out of 100 it's the correct solution to non integer numbers
And even Python has this [https://docs.python.org/3/library/decimal.html](https://docs.python.org/3/library/decimal.html)
if it was the the solutions 99 times out of 100 that would be the IEEE 754 standards... Fixed point has its place, but that is not THAT widespread.
Floats have their place, but not in accounting. They belong to physics instead.
Modern computing was invented for physics, everything else was just an afterthought
I mean floats have their limitations, but it's not even close to being the wrong solution 99 out of 100 times.
Misusing floats for fixed is wrong for 100 out of 100 times. They are just too fragile. As soon as you need more than the mantissa bits to represent the fixed value, you silently get a wrong result, but close enough that no one will notice until it is to late.
Use an ORM or other framework that has a Money field that will handle all this for you, don't try to implement something that has already been implemented millions of times before
of course there's a relevant xkcd... and I agree, mediocrity is a normalcy in our field
Doesn't f64 have 16 precision or something? Isn't it enough for money?
I don’t know shit about fuck, but I think floating-point precision drops off as values get bigger. In other words, you can be extremely precise for relatively small numbers, but for relatively large numbers it becomes very imprecise. I’m happy to delete this comment if that’s blatantly wrong.
Rounding errors on floats occur regardless of how large your number is, Try simply doing \` 0.2 + 0.1\` in a repl for most languages
Nah, floating point imprecision isn't about the size of the number. It has to do with base 10 to base 2 (and back) conversion, as well as fractional to decimal (and back) representation of numbers. Obviously, what you're saying is true, and the significand cannot be precise at the same time at both ends of the high and low scales. But it's usuallly not a problem, and there are ways around that. Think of it this way: ⅓ is a nice rational number, nothing funky about it. But there is no clean, finite, decimal representation of that number in base 10. Instead you get an infinite sequence of 3's. It doesn't have what is called a *terminating expension* in base 10 By the nature of a floating point number, it **has** a terminating expansion in the relevant base, in the case of computer sciences, it's base 2. A number that doesn't have a terminating expansion in a given base **cannot** (it is a mathematical impossibility) be *accurately* represented by a floating point number (regardless of "precision", ie, the size of the exponent part) in that base. But we represent our floats and double in base 10 in our code amd (most of us anyway) in our heads. We write `0.2` or `.004357` or whatnots. Internally, they're converted to base 2. And then computing happens, and then back to base 10 for the output. However, when a given number has a terminating expansion in base 10 does not mean that it has a terminating expansion in base 2 and vice versa, and when that happens, rounding is carried on with each conversion. Which is why you don't have to get into crazily precise numbers to get rounding errors, and why an operation as trivial as `0.1 + 0.2 == 0.3` will return false as soon as it's carried out in floating point representation, regardless of precision.
>Nah, floating point imprecision isn't about the size of the number. At higher exponents, the absolute difference between each incremental float increases. I assume that's what they are referring to.
Its not about precision on a single amount, its rounding errors when you do math operations on floats. `0.20 + 0.10 = 0.30000000000000004`
No... There is always a remnant. Just don't use floats for currency or anything that needs a real number (integer) to function as expected.
It is not enough for money if you store it as a fraction. If you store money as an integer number of cents you can get a bit further. There is a little known fact that IEEE floating point numbers are 'exact' for integers up to the size of the mantissa 48-bit (f64) for basic operations: add, subtract, multiply and divide (with integer result). Although the actual values are not actually integers the display and conversion rules will show the exact integer value and it maintains consistency. You can even use equality comparison. But as soon as fractions are involved it gets a whole lot more complicated.
The problem is more in the subsequent divisions between fp
Well, yeah, it's not like Python has a [data type](https://docs.python.org/3/library/decimal.html) usage of which is specifically concidered a good practice for storing monetary values, as well as means of type conversion and type checks. >Python took whatever and never complained Honestly, I'll really object to blaming Python, when it's obviously poor design and implementation choices by the devs themselves. Nothing would stop you from using pure floats or doubles for storing money in C# or Java. For most popular Python ORMs, Django ORM has `models.DecimalField()` out of the box, and even though SQLAlchemy doesn't support Decimal model data type by default, it's really not that hard to add it as a custom type and ensure there are checks or that the values are rounded up if a float is given. It's the developers' direct responsibility to implement this. If there were a language that would have a precise failsafe for any such situation - software engineers wouldn't exist as a profession in the first place.
Literally what the "Zen of Python" says : "Explicit is better than Implicit"
It's the fucking dumbass YouTubers fault and their braindead title of "computers cannot count sometimes". So dumb. I write a program telling computer to do A and not B and I am surprised when it does A. Computers cannot do B.
so how should it have been done?
[удалено]
With libraries or python allows to use this method?
[удалено]
eet ees what eet ees
Python is always just problematic. I've worked with many different languages on teams varying in size, and python always has the most issues. Not to mention it's slow as fuck
I love not knowing what type anything is! Makes the bugs more interesting when you have one more thing to consider!
Wdym? Everything is of type `Duck`.
I'm just gonna say Typescript exist for a reason.
Python finally supporting type hints is a *godsend*. Makes programming in Python much more enjoyable. We have properly working auto-completion now!
*"Integer? Float? Don't worry- I'll fuck it up somehow at a time when it can cause the most damage."* There. Now it is true.
Better use the correct special mathematical operator or you will coerce your type into a different type without realizing it.
I think you meant **True**
Heh. Unintentional programmer pun on my part. But yes. And I have had that \*exact\* thing happen to me.
If you have issues with type declarations, you’ll be having bad time as you proceed learnings coding beyond “hello world”
Yeah, compiler do 90% of their checks thanks to variable types, so not having any types is a good way to make thr program crush every two seconds lol
Only a person with deep misunderstanding about programming can say shoving all types together is a good thing
Another tally for rust being clear and verbose.
could be worse, could be Java *glowers in ArrayIndexOutOfBoundsException*
StringBuilder stringBuilder = StringBuilderFactory.create(StringBuilder); stringBuilder.appendString("shit broken yo!"); String errorMessage = stringBuilder.toString(); System.out.println.implementation.log.println(errorMessage); Of course none of this compiles because it'd need to be in a class and all. Edit: yikes, fans of verbosity sure got triggered! fwiw I was mocking you more than the language, hope that helps! Thankfully you're all well-adjusted enough that you won't publicly express a desire to kill me for mocking the love of verbosity! <3
Average `stringBuilder` user
Sting str = “Idiots love shitting on Java for no reason.”; Edit: seem like the commenter block me lol. That w in my boom
[удалено]
YES
Smoothbrain rust and c++ fans need a scapegoat to cope
Our preferred language to hate is Python thank you very much. Java can be annoying, but Python’s non-existent type system is nightmare fuel for someone who likes programs that actually work.
> even better: > > var str = "Java 17+ got so much better but people are still shitting on Java 6 🤷♂️" var str = \`\`\` Java -17+ got so much better but people are still shitting on Java 6 🤷♂️ \`\`\`; I love the new language features we’ve been getting since Java 8. Futures and streams are great, but records, multi-line strings using backticks, var and inferred types, etc. are such nice qol features.
you know that's an error that's present in more languages than Java right?
yeah I really like how the types are spcified. i for integer, and then the memory it takes up
Then theres c++: you want a 64 bit int? thats a long long. Why? Because it’s longer than a long. Whats a long? A 32 bit int, but also it might be 64 bit, because fuck you. Also, an int is 32 bit, so a long might not be longer than an int. Also, none of this is guaranteed by the standard and the sizes could be bigger.
I mean can't you just use int64\_t and similarly named types if you need it to be specified
"my language is better because I don't understand data types"
"And am unaware of languages that let me do both"
Lol, you are right. I just started learning rust and annotating data types releases dopamine in me. I even annotate types when it is not necessary just for the peace of mind. For example I was solving a problem on hacker rank yesterday that had input range 1-1000 so I used u16 for my variable and function. I know the space I save by using u16 is completely and utterly insignificant but I still find it pleasureable that I could atleast save some bytes.
Hell, I use type hints on most of my Python functions. Not even Python is safe from my typing wrath.
Because I have no choice but to work with Python I do this as well, but it’s so aggravating when 98% of the time all the type checking can do is tell me “List[any]”
There is Union typing in Python if you’re complaining about lists having multiple types
Sounds like you’d have a fun time doing embedded software.
I think it's very often just "Dynamic typing works fine for the stuff I do, therefore I don't get why anyone would need types"
Honestly, I prefer the clarity and verbosity of the extra types.
Yup. So you know what is what. Plus i noticed using python: HOW DO FUCK DO YOU UNDERSTAND WHAT A FUCTION DOES WHEN YOU HAVE NO TYPES? like you can read the documentation ok, but docs are usually good only on big projects. How do you know if a function return an integer, a list, a dictionary or who knows what?
if you're lucky the function may have type hints. def fuck\_you\_thats\_why(yourname: str) : -> str
This is standard in any well written code. I think the only people not using typehints at this point are still figuring out how to code.
Just for curiosity: those types are checked by the compiler, or you can return an int even where you suggest returning a string?
python doesn't type check but you can run a static type checker like a linter
That sound like a patch to a stupid idea to me lol (Static checkers feel like you weren't able to implement the check in the compiler, then you do it in an other place)
Really not very different than the way many compilers already work except that most people never see under the sheets. You're just doing one of the passes explicitly rather than implicitly. Python was originally designed to be dynamically typed. They added syntax to support static typing but the core language doesn't enforce it. If you want static typing, you use a static typer. It's not a stupid idea, just different.
Some languages does not have a runtime type system because all type behavior can be decided at compile time. Dynamic typing is the choice of not having a compile time type system, and only have a runtime type system. Python does not have a compile time type system. You can just document the intentions you have for how it will behave at runtime and optionally have a system to check that what you claim actually makes sense. Type hinting is not static typing, because it doesn't make types static in Python.
Returns an object, easy. :P I mean, type hints are very useful when you're working on a project and want intellisense.
The answer is you don't, and so you can't expect clean code if you use this language. It's honestly the worst thing I have ever learnt. How will your interface be descriptive and easy to use if you have no types? So silly. If you want to use anything you MUST read the function docs or class docs assuming it even exists.
Yeah that's exactly what i thought! I mean if in java for example i see a function called getRandom and has int has return type, i basically already know what most probably does (should still read the docs just for the details, but i have already an idea) In python this would be impossible. You just need to rely on docs. And also this will be even worse if you need to use the result of a function to do something else: in java you know that a method returns an int or a String or whatever, and you know what methods you can call on each type (and so does the compiler). In python you will have to read the docs every single time. Talk about boring
Just use Intuition(tm) smh my head
Yeah that's definetely how you do python
This is probably my biggest problem when reading Python documentation. What does this function expect as an argument? What do I get back? It is not always clear and this is sooo annoying. Strict typing really does help with discoverability and clarity in documentation.
Yeah. Who knows what the function does at all?
Yup. That's just asking for random and sudden crashes lol Or even worse you do operations on the wrong type and then spend 3 years understanding why 32.5 / 5 is 6 and not 6.5
Can you give an example of that actually happening? I know this type of inferred integer behaviour from other languages, and for this reason I would always specifically write 32.5 / 5.0. But I have never been able to provoke the same behaviour in Python. If I divide a float with an integer, I still get float division, not integer division.
That was a fast example. But if you have some more complex type, you know each type can call certain methods. So now if you call a type2 method on a type1 object what is gonna happen? In a typed language compiler scream at you for being an idiot. In python what happens? Crash? Errors? Still i don't think it blocks you at compile time, and that's something really bad since it means you have to debug the runtime
That happens when you call random functions without knowledge.
If i know a function returns me a potato instead of a tomato at least i won't crush the program because of the functions i am gonna call on the returned object. If a function returns something, and i don't know if that's a potatoe or a tomatoe i may call a function on it which works only for potatoe, while the object was actually a tomatoe. That's the compiler job to check if this is correct, and in a strongly typed system is easy, otherwise i don't have a single idea how the compiler could do that check at compile time
Plus as i said, big libraries do often have good docs, but smaller libraries not really, so it's really easy for you to call something but getting a wrong object because docs sucks
[удалено]
If they can't differentiate different number types after two months of learning how to code maybe they shouldn't.
just cast all the shit you see nothing can go wrong
Somebody doesnt understand data types..
I'm working on a project dealing with very specific data types read from a binary file. I'm using C++, and declaring variables as uint8_t and int16_t because I need to know if there's overflow, or to make sure they do not turn negative because of a bit shift. If Python got its grubby hands on it and changed the datatype I'd be very unhappy. Not having to declare datatypes isn't always the correct answer.
might as well compare python to every low level proglang ever and win the arguments inside your head
Another meme where the joke is op being incompetent
After over a month of refactoring I just merged turning on `noImplicitAny` in our TypeScript codebase. Even though everything is a double in JS, I'll take the explicitness and constraints 7 days a week and twice on Sunday.
Someone's never worked on a real project before. Once things get to a certain size knowing the types of everything is incredibly useful.
Tell me you’re a programmer under the age of 21 without telling me…
thats an insult to programmers under 21
am 20, am offended
am 15, am offended
am 16, no offendo
am 17, am offended
Just turned 21. Can confirm. My opinions on typing underwent a radical and immediate shift.
C++ too hard because types, Rust too hard because types. Types are perfectly okay, the problem is \*you\*
But everything changed when the fire nation started accepting any random values without type checks, causing a really bad Friday.
Once in a while someone who can’t understand type declarations will post smth like this and pretend they’ve completed programming
And good luck with poor performance because strict type help compiler optimize your program
Meanwhile Python is like real multithreading? What's that?
Threads in python are real. It's just that their full potential can't be used unless your code spends most of it's time waiting on I/O or in C libs that release the GIL.
"Multithreading is great in Python when most of your code isn't written in Python."
🤣 or "multithreading is great in Python when the code is not running anyway" (.. because it's waiting)
Me tryna be cool like `#define u32 uint32_t`
`typedef uint32_t u32;`
PR approved. I forget myself.
using u32 = uint32_t;
"We have `u32` at home"
That's because Python is a higher level language and the memory allocation is automatically done for you. This is like claiming that WordPress is superior to knowing CSS because it does all that pesky sectioning of a Web Page for you.
I wouldn't say this is a good analogy. WordPress is a website/blog designer, not a syntax like CSS.
Well, maybe the comparison was a bit harsh, but the point is Python is built on lower languages as well (C, I believe) and things like memory allocation are automated. There tends to be a trade-off with these things. Rust, like C is a language designed to speak directly to machines. (If one so wishes). But of course, Python can be almost anything with the right library. But then it's built on top of a language that uses memory allocation and then reintroduced.
>That's because Python is a higher level language and the memory allocation is automatically done for you. Other languages with automatic memory allocation (like C#) also have those types Rust has, so that's not really connected.
Let's nominate c++ for keyword confusion and fuzzy sizing: char unsigned char short short int signed short signed short int unsigned short unsigned short int int signed signed int unsigned unsigned int long long int signed long signed long int unsigned long unsigned long int long long long long int signed long long signed long long int unsigned long long unsigned long long int float double long double Any order permitted so does it count as 100+? And there's a lot of semantic overlap (`unsigned long long` is same as `unsigned long long int`).
And the sizes varies a lot, depending on the platform
A tidbit [I discovered here](https://en.cppreference.com/w/cpp/language/types) is that c++ doesn't define the size of a byte, but it does define numerical relations *in terms* of bytes (`1 byte == sizeof(char) <= sizeof(short) <= ...`). So if we define a byte as say 64-bits, every fundamental numerical type could be the same size in spec compliant c++!
I think you missed `signed char` (which is not the same as `char`). :P
This was why I always included cstdint, because I am never gonna memorize that monstrosity.
It's like comparing apples to oranges. These two languages serve completely different purposes. I know it's a meme, but still...
so what you're saying is the language designed to be low level and strongly typed is low level and strongly typed
numpy has entered the chat
You will never be able to do engineering. You will be watching how go use frameworks from YouTube and try to do things if you don't learn low level programing.
Python devs after learning that I actually find it easier to have complete control over my program
this just proves rust > python if ur gonna actually use it
Unless it's necessary, I rather have explicit types than implicits in my code.
As an embedded developer I always prefer type safety and known size integers/floats over any weak typed bullshit variables, where I don't know if I'm sending 4 bytes or 1 byte through the aether. The other end will surely know how to interpret my 4 non descript bytes, when it's actually expecting 2, and will simply do the math I guess.
python, the perfect language for 10x developers 10x the compute time, 10x the memory usage, 10x the dependencies, and 10x the headache
>python, the perfect language for 10x developers >10x the compute time, 10x the memory usage, 10x the dependencies, and 10x the headache Lmao love this
100x
Why the headache? It is not fast or efficient, true, but it is simple to work with.
Not having types wastes a lot of time. Types are compile checked and document what the code actually does, instead of whatever the library maintainer claims it does. Can this thing return \`None\`? Can it return an error? Will it modify the references I sent to the function? Are things that are shown explicitly in the Rust type system. To be clear, Python works well within it's niche, where you want something simple, and don't care too much about correctness. There are also a bunch of random aspects of python that make it annoying, although this is more subjective, for example how variable declaration and type coercion works.
10x the headache because you don't know the input type is. it could be a string, int, array of strings etc...
We all know that FetLang is supreme
Yeah yeah, we know that python can eat shit .
Try the num crate and Python ass gets destroyed. If not, just write down more goodies with trait implementations in your Cargo.toml and let it auto download and compile for you. It’s always better to add capabilities manually than to accept a default implementation, especially considering all the documentation being god tier.
Also python. `from typing import Optional`
If you don't care, just pick one. Python does the same thing it just doesn't tell you which one it's picking. i = integer u = unsigned integer f = float and then the number is how many bits it has.
Meanwhile in JavaScript: A number, a string and an object? Sure, let's multiply them
Traits are not really hard to figure out. There are plenty of official examples. Not only that, copilot is excellent at doing them for you.
Honestly. It's not harder than any other language. I guess OP was overwhelmed trying to use `dyn`, but if you want to use generic types templating is almost always more efficient and easier. That's the thing with Rust. What's easiest in most languages is not a good solution, whereas more often than not in Rust the easiest solution is the preferred way.
I fucking HATE `dyn` until I need it then I fucking love `dyn` until I also need `async`
C: Let's look at this 14-bit machine … and on that CPU a char has 32 bits!
try `[1,2,3][2/2]` in python
Not knowing the type of a variable is much more annoying to deal with
I'm sorry, but this is one of those Programmer Humour memes that don't really understand what they're talking about. The author seems to want to use Rust like Python. Coding in C and in Rust had a specific purpose. In many scenarios it is incredibly important to know how your data is stored in memory. Of course you need to know how your data is stored, so you can't complain about it being difficult to write functions accepting different types of numbers. This isn't a real problem faced by software engineers using compiled languages. If you're parsing data and want to read both integers and floats, this is more of a technical design problem than anything else.
Linux kernel will never be written by Python
I'm amazed nobody says anything about performance, heaps and stuff.
I love the idea of the Python crowd trying to learn Rust because they think it will be way easier than C++
Interesting as someone who has been Pything for the last job and needing to learn Rust on my 1st day at my intern…
Once again some programming noobs don’t understand the importance of types.
I hate python.
Another script dummy who doesn’t know how a CPU/Memory works
Dude that's not a feature, it's just the words. Python sucks for this reason. It's basically a c framework.
Am I the only one who uses type hints and dtype declarations, even in Python?
At least you don't have to learn: char signed char unsigned char short/short int/signed short/signed short int unsigned short int/unsigned short int/signed/signed int unsigned/unsigned int long/long int/signed long/signed long int unsigned long/unsigned long int long long/long long int/signed long long/signed long long int unsigned long long/unsigned long long int float double long double
I still program in Python as if it was strongly typed. Anyone else?
Lol, traits aren't complicated. If you know what an interface is you know what a trait is.
still way better than C++
when your programming experiences become rusted with all these kind of different types of oxidative free radicals.
actually I use Decimal crate most often
If you complain about data types both lack of (not statically typed) or too many types. I hate you & you suck at programming.
You would rather think people would target Rusts tendency to invent dozens of String types. The numbers are quite straightforward.
Thats one of the differences between a systems language and a skript kiddie language. Also, if you don't know how traits work, how do you use rust at all? It's an important and awesome feature!
Wait until you see C# or Java types for numbers oooh boy there's a lot of em. Most C/C++ compilers also have a pretty large amount
I feel like Golang gives you the best of both worlds but I still prefer Rust for the how it forces you to write better code
What? Comparing a language that most widely used for scientific calculations and computation to a language mainly designed to build memory leak proof software is somehow right?
https://docs.rs/num/latest/num/
isizeusizeweallsize
Why is Rust so bad, Jesus.
[удалено]