Languages without a fully implemented type system.

Granted, it has been a fad for a quarter century, but everything points at one simple fact: Types matter in programming.

In dynamic languages, you tend to see that testing suites explode into thousands of tests, many of which wouldn't even be necessary if you had some type safety.

You see that languages like JS are forked into more typesafe dialects, like Typescript. Python got typehints since 3.6, and PHP added typehints for methods, then typehints for properties, and will soon even have compound types.

Maybe most languages will never reach the level of Haskell or Scala, and that's totally fine, but I think the direction languages are moving in is pretty much set in stone: No ambiguity, more safety. Code should fail before deploying, not after.

You don't need types if you respect types to begin with.

Declare a variable as an int, you treat it as an int, same applies to other types as well.

Type safety is a thing, because sub-par devs are useless and recycle variables at will.

@C0D4

I disagree. It's not just about code you write, it's also about code imported from packages.

And to be honest, I have very little faith in developer discipline -- not because developers are "sub-par". My discipline sucks as well without rules which are enforced by code.

Every developer makes mistakes, that doesn't make you sub-par.

Every developer only works as neatly as required by the syntax of the language combined with linters & tests, because the pressure to produce is always greater than the pressure to write maintainable code.

I maintain a 35 million lines of code PHP monolith -- just the simple act of gradually enabling strict mode on every class, and setting a CI/CD rule which checks every new class, has reduced the amount bugs significantly.

Absence of types is technical debt in my experience. There is no developer on the planet who can continuously and actively "remind themselves to write correct code".

@bittersweet don't get me wrong, I didn't mean "sub-par" as any dev that doesn't respect types, I was more meaning script kiddies who think they know what they are doing and don't.

I understand the lack of time element which will push people to do the wrong thing to meet a deadline, but that doesn't excuse implementing bad practises, why meet a deadline if you're only going to have to rebuilt it?
that doesn't save you or the business money, it creates an instant debt.

You don't need to pull out the LOC on me, I'm solely responsible for about ~8mil over 4 legacy php platforms, there's no frameworks behind these, if it wasn't written it's not included, and that's not including SDKs and shared libraries.

But in saying that working with strict type languages on a daily basis also encourages using these, standards if you will, in languages that don't have them.

Also, I don't use linters, they get it my way more then they help, and no I don't use non standard formatting, Formatting code isn't hard to do though but it comes down to discipline like most things.

@C0D4

All I'm saying is that weaker typed languages are either on their way out, or staying alive by strengthening their typing features.

I think devs are noticing that type systems cost a bit of time to get used to, but save much more time in preventing bugs.

Tl;Dr types exist to make code more provable, and therefore more checkable by tooling.

@SortOfTested And 9 out of 10 times, it does a better job at it than unit tests.

@bittersweet
10/10 times, unit tests + types scream at people trying to fuck up logic

Hehe, types are "new" trend 😎
Besides of strict linting and provenance of project's codebase, libraries with type declarations make it so easier for me to put proper object without switching my focus to documentation, when I just forgot the type/class. That's so convenient 😌

Interesting, even gdscript in Godot is moving in that direction.

@Demolishun hello Godot fam =) Yeah, it was superb idea to make new language for optimizations in engine, makes even embedded scripts look promising.

@C0D4 all these piss contest with locs on devrant...

@aviophile 🤷‍♂️apparently it's a unit of measurement.

@aviophile My brain can only hold 4 or 5 though. Single lines.

I don’t like to write js as frontend, always typescript even if I don’t completely use the type system.

Just today I wrote a deploy script in node and half the time I was „wait was that this env string or the boolean check to the string“. In those cases, I tend to name the content type as variable like isProduction or shouldUseRelativePaths

I like the flexibility to be type strong and in some cases loosely, e.g. feature prototyping

Super late to the party here, but i do want to note that type safety has to be coerced out of devs who CHOSE not to learn how to do things the right way.

I have a DBA who inputs all information as strings, including boolean values as either "yes" or "no", and integers the same way. And no, its not NoSQL. When we wanted to get structured data from him, i made him give me json data, but it was like i said. So when i made him do it correctly, it definitely showed his incompetency when he wrote his own fucking json parser instead of just writing a broker.

So of course not all of us are in a position to tell data providers how to give us data, but what we can do is consistently strive for type safety in our own code, and then hopefully the world will follow suit.

@010001111 I always use VSCode with JSDOC because of that. I define the custom types in comments and I can see what type is it whenever I hover over it.

Good old C/C++!

@SnowGuard Things are never both good and old.

I'm old, and much like C++, I'm more of a Chaotic Neutral. Every time my gf asks me to do the dishes, I segfault.

JS is Chaotic Evil. Java is Lawful Evil. Go is Chaotic Good. Rust is Lawful Good.

Although, that's just my personal perception of languages...

One thing I like about python is the ability to duck type something. Add the functions it needs to behave like the object I need. This has been useful when switching object types part way into a project.

C++ can do this with templates and auto now. Which I find to be very interesting.

@Demolishun
Definitely. I still prefer structural typing, but duck typing is great for flexible runtime checking. C#'s Dynamic types do interesting things with that.

@Demolishun I don't think ducktyping is necessarily a problem, as long as it follows very unambiguous rules.

Ducktype only exists for types which are similar, or can be interpreted as being similar.

Humans don't necessarily treat ints and floats differently in real life, 1 is not something entirely different than 1.000. But for a computer to ducktype those, you need consistent float behavior.

I think a better solution is a generics/trait/typeclass system, which allows you to specify what "<" means to a deck of playing cards.

@bittersweet I need to get more versed on that in C++. I know there is stuff in there for that. I implemented an iterator the other day using traits I think. Is that what you are talking about?

@Demolishun

What I mean is, expressed in C++ specifically, is when you define a Fraction class to hold infinitely repeating decimal numbers like 2/3, and then overload the "*" operator.

Fraction& operator*=(const Fraction& rhs) { <some logic to deal with numerator/denominator and Fraction simplification> }

Now you can do 2/3 * 1/2 = 1/6

It's not really ducktyping, but it allows you to implement a single function or operator for many different types -- whenever it makes sense.

In some languages, common type properties are organized in traits or typeclasses

For example, in Haskell you'd have

class Eq a where (==) :: a -> a -> Bool

Which means that == is a function, belonging to typeclass Eq (equatable), which can be used on any type a, which can be compared with the same type to result in a type Bool.

Then you can implement == by creating type instances of the type class.

instance Eq Json where <logic to do a deep recursive comparison of two Json objects>

@bittersweet
Damnit, stop making me want to Haskell, I have to survive another 2 months of this imperative hell :|

@bittersweet Yeah, that is really close to what I did for the iterator. You define properties with values that determine what functionality the object provides.

@Demolishun

The cool part about that is that another function can say:

Hey, I'm typesafe! But I really don't care about the exact type you're putting in me, all I care is that it's of the typeclass Eq.

For example, in Haskell, the type signature of sort is:

sort :: Ord a => [a] -> [a]

As long as type a implements "<" (Orderable), I'll sort any list of "a" into another (presumably, sorted) list of "a".

Playing cards, pizza's, dogs, as long as you give me a way to put them in order, I can sort it!

But isn't this what Interfaces do in OOP?

Yes... partially. But in most languages, Interfaces are kind of limited -- if your function would accept anything that implements the Interface "Ord(erable)", you could end up trying to put a Playing Card and a Float in order. Both are orderable, but not with each other.

That's why many languages have overloading & typeclasses (Haskell) or traits (Scala, Rust). In Kotlin, Interfaces are actually full-on polymorphic traits.

@Demolishun

Also, PHP traits... are not traits. They're cancer.

@SortOfTested

http://learnyouahaskell.com/chapter...

That's what evenings and weekends are for... or meetings, when they're boring as fuck 😄

Shout out to typescript. It adds type safety and etc to a language that doesn’t need it. Which is kind of awesome because then we can do the work and when it makes sense to ignore types, like when converting to a object from json, you have the flexibility to handle it.

I have been working in a language similar to Java recently and it takes a ton of work to get a property from json and convert it to an object.

“Oh now I need an interface and a class to describe the parent object that I will never use again just so I can deserialize it enough to collect the object at a property. “ Types suck for some things because they need support just to do simple things.

@irene In that case, maybe types don't suck, maybe the language sucks because it has a bad set of type coercing rules?

@bittersweet
This, Jackson and a data class doesn't seem like much work.

Amen.

@dUcKtYpEd until js++ and js# comes up and Microsoft gets bankrupt

@bittersweet Could be. I would rather be stuck with loosey goosey JS/TS than a crappy strongly typed language. At least there are workarounds for everything.

@irene I would be lying if I said I was smart enough to design the "perfect programming language" (if such a thing can exist), but I feel like many languages have made a design mistakes which seem incredibly dumb... in retrospect. Completely understandable given their roots, but dumb with current knowledge.

I am happy that pretty much all languages with such a history are at least moving in the direction of "slightly strongly typed", instead of staying "ambiguous and confusing" in an attempt to be "easy".

@bittersweet
Daniel Rosenwasser and Anders Hejlsberg are pretty excellent to follow if youre interested in the building of languages that meta-compensate for the failures of other languages.

Edit: Erik Meijer as well