/prog/ - Programming

>>2590

> accidentally f (b, a ) instead of f (a, b)

> oh noes I got some weird and obscure error in my untyped language whereas in my typed language I would've immediately got the error that the type is wrong

Either that or I do g (a, b) and immediately get an error in typed languages.

More seriously. Here's how I usually do my programming. I look at what I need as input and output, and then write down all of the functions I would need. For example, I need fns to read files, fns to transform from a data structure to an other, do the actual work, and write to file. It's a loot easier if the functions are typed cus I know what goes in, comes out, and I won't get stuff mixed up in my head. Basically it's easier to organize.

Another huge advantage is that there's a possibility you can speed the code up a lot if it's typed.

Clarity and readability.

Dynamic typing doesn't add anything that isn't immediately obvious like converting float to string. Which is the main reason why you aren't coding everything with a base object (void* in C++, "dynamic" in C#). It would also be needlessly slow.

Really you DO need strong typing because otherwise it's not clear what you're actually doing. Each object instance and its method call actually refers to a syntax pattern of the program code structure. So without this it's more unclear what the fuck is going on when you're reading someone else's code.

In the future I'm 100% convinced we will see much more abstract programming code, for example, I just made a c++ base class that does automatic garbage collection (emulating C# almost), I only need 2 lines of code in my class constructors and there's 0 memory leaks without manually tracking ref counts everywhere (obj->Release()). Eventually it will get easier and cleaner and you'll need the minimum of configuration. BUT, strong typing? I don't think it will disappear even in decades to come. Logic wise (high level), it's actually really useful, and problem solving is always done on a case by case basis (bespoke, focused, time intensive = familiar).

>>2749

And all this is because what you're coding is to do with syntax itself. Your program code is made to fit the problem's logical components, and this won't change. Object Oriented programming is not going to disappear, because it's ALWAYS going to be useful to separate aspects of your application/software into separate objects or components.

Visual programming (UE4's Blueprints) is INCREDIBLY primitive and tedious and clunky. Programming by hand can still be greatly improved from messing around with pointers in C++, but still, for that to happen you're still required to know WHY you're avoiding the low level code in the first place. So you still need a good programming education to use amazing tools. Otherwise you have no context for why you're doing whatever it is you're doing, you don't know what to do.

Programming by hand is just far more flexible and dynamic than any gui system could ever be (you're limited by very limited gui flexibility) - it gives a fine grained control, in a very compact amount of screen estate. You could NEVER program an OS with gui controls unless its design was extremely nuanced=specific=niche. You would need to create the visual parallel of IntelliSense, and it's just so complex (all systems design is) when you haven't even set out to know your project requirements yet because they're fucking interdependent with what you're able to innovate/achieve.

So basically nobody will get past strong typing ultimately because this is what underlies the very systems we use today = the very things we are actually creating off of. ASM to C++ you might say, but no, this pattern is much more general. It's not like Object Oriented programming will become something else next year. There is nothing that fits it better that becomes free from the previous underlying paradigm / "expression model". There's NOTHING more convenient AND flexible than strong static typing. If there was, it would also be about as obvious as OO programming,

and with flaws (like remembering what your custom compiler or memory pool manager is actually supposed to be fucking doing).

The path of least resistance is just to follow on from what other people are doing. If you need something like UE4's Blueprints, chances are, you're already encroaching on territory where the application is niche = you assume a lot of the context for using it (graphics/game). This is a required step when you make something specialized. We just don't usually have the resources to reinvent programming.

But of course if anyone DID reinvent programming from ASM (computing = "Turing machine"), it still wouldn't be dynamically typed, because that just offers no INFORMATION about a type.

It comes down to what expression even, itself, is. Parts of my programs are highly specific, and this is Inferred from the type/object. It's just part of the nature of programming itself, it's unavoidable. Unless you want to create something new (like UE4 Blueprints) where you assume certain things at certain times - but as I said, that has no general use because it's for a specific application.

Simple answer:

I prefer dynamic typing for any one-off things, due to less typing.

But for anything substantial, I prefer having as much as possible caught early. And static typing enables that. There are many things that (most) dynamically typed languages don't catch that they could at compile-time and/or write-time.

If there was a dynamically-typed language with both optional static typing enforced at compile time and with an IDE with warnings when a function call will throw an exception, I'd use it. But that's difficult-to-impossible to do. Especially as with a statically-typed language even if you don't have the source you can still do this to an extent, but with a dynamically-typed language you generally cannot.

About the only time I find dynamic typing much better is if I'm doing something weird like making a multiset (i.e. key -> set of values) with the optimization of not storing a set of values if there is only one value, just storing the value itself. Or something similar.

But in general if I can have something be caught early, I prefer it, and caught as automatically as possible, I prefer it.

Simple answer:

I prefer dynamic typing for any one-off things, due to less typing.

But for anything substantial, I prefer having as much as possible caught early. And static typing enables that. There are many things that (most) dynamically typed languages don't catch that they could at compile-time and/or write-time.

If there was a dynamically-typed language with both optional static typing enforced at compile time and with an IDE with warnings when a function call will throw an exception, I'd use it. But that's difficult-to-impossible to do. Especially as with a statically-typed language even if you don't have the source you can still do this to an extent, but with a dynamically-typed language you generally cannot.

About the only time I find dynamic typing much better is if I'm doing something weird like making a multiset (i.e. key -> set of values) with the optimization of not storing a set of values if there is only one value, just storing the value itself. Or something similar.

But in general if I can have something be caught early, I prefer it, and caught as automatically as possible, I prefer it.