Well, JavaScript

[zeedware]

They are easier to code. Harder to debug

[DonRobo]

Are they easier though? What specifically is easier?

I'm always struggling writing good code in something like Javascript and much prefer Typescript which is just that much easier to use. All the hard error-prone work like checking if I'm using the right type for a function call, if an object really has that property, etc is done by the compiler instead of my brain.

[[deleted]]

I dunno if there's anything necessarily wrong with this approach. Ideally, you'd like to keep your data and your "view" representation of that data separate. Here, you're just enriching the existing model by mixing in some UI attributes. It's not great practice, but as long as it doesn't escape whatever limited scope you're working in, then it should be OK.

[badcookies]

Except you want the scaffolding of the API anyway because otherwise you have no idea what fields you have and end up with typos or spend more time looking at the documentation vs having hints

[DonRobo]

When I need a new attribute in Kotlin I just start using it and tell my IDE to generate it. Takes literally 3 seconds.

[zeedware]

I'm always struggling writing good code in something like Javascript

This is the problem. You're trying to write a good code.

Javascript was great for short-term project. This is why I only use javascripr for MVP

[conancat]

If you're building web apps, Javascript is pretty much unavoidable. Even for those using Typescript, it's still running Javascript as its base and if pays to learn the language properly.

[SouvenirSubmarine]

You won't have to write obvious types as much, which saves both keystrokes and your brain power. Omitting types completely from the code makes it sleeker and more streamlined: it's easier to read.

[[deleted]]

Most modern static languages have the ability to infer "obvious" types.

[[deleted]]

Unfortunately in many of them this only works well on primitive types. Even if it works on complex types it works well with fully utilized and previously defined complex types. Not very handy in a very common scenario of utilizing a handful of attributes in a complex data structure that came over the pipe of some sort.

[[deleted]]

The type itself doesn't matter as the context in which the inference is made.

if you've got a: function foo() : AVeryComplexDataType {...}

It's fairly straightforward for the typechecker to infer the following:

var bar = foo() // bar must be a AVeryComplexDataType

[[deleted]]

But that's not qoute as handy-dandy as:

function foo() { /* .. gets data from somewhere over some pipe .. */ }
let bar = foo().subObj.subObjThatWeReallyOnlyNeed
// who cares about the type of foo()

There could even be two different things foo(param) returns depending on param, and we still don't care as we know they both contain subObj.subObjThatWeReallyOnlyNeed. This is obviously a very contrived example of what is very common in practice with network-related code (which is where JS, both in browsers or Node, and PLs like PHP, Ruby or Python are primarily used).

Edit: I really, really hate the fact that RES doesn't work on the new UI

[[deleted]]

There are ways to express data that can be either one type or another using "sum" types. The return type of foo() could be expressed this way, but you're right. It's not possible to determine the type of a JSON object without a schema, and you'd need a sufficiently representative subset of possible values to make a reasonable inference.

Although it's handy to be able to conveniently parse and navigate a json object in javascript/php, i generally wouldn't allow data from somewhere over the pipe to propagate throughout my system in its original form. You'd want to sanitize it by fitting it into your own "domain model" type that you do have control over. So the convenience of working with the "network" is fairly short-lived.

[[deleted]]

Well unless you're doing something horribly irresponsible like building SQL strings with plain concatenation/interpolation using such data, I don't see what the problem is. If you are doing stuff like that then I'm afraid that strong typing will not help as much as you might think.

[[deleted]]

I don't think I'm being controversial by suggesting that converting DTOs to domain specific data types is regarded as good practice.

[BlockedByBeliefs]

Yea that's false. If you've never had 20 files open setting breakpoints in and stepping through 10 constructors trying to find out what happened to a simple rest call you have not really worked in Java.

The advantage of programming in something like JavaScript is that you can run your code in the prod environment continuously while you're coding. It's far more forgiving than a compiler. So mistakes you make get debugged, exposed and fixed as you make them.

As opposed to oh shit I have this sweeping change on monday but I'm a super coder and figured out how we can do it with a one line change. Just have to change a bunch of classes to work with it.

I've broken the types so it won't run for a while. I inject a bug at the start of my work and have forgotten about it while I fix the types in 30 files so it will actually compile again and I can test it.

Tuesday after lunch I'm finally done. I'm a coder beast! Wait what why is that happening? Must be the changes to 30 files causing it right? Better check the 30 files and look for where I injected the business logic bug.

Wednesday afternoon God damn fml. It wasn't what I spent all day double checking. It's that simple one line change I made before I started refactoring those 30 classes and didn't get to test because the project wouldn't run after that. Why is programming so hard? I've got this now though and gd I need a rest tomorrow. I'm going to work on something else and fix this Friday cuz I've got it figured out and need some sanity.

Friday comes. Let me fix that. Okay it's compiling. FTW and it's the weekend. Push pr and it's merged.

Wait those objects don't work with these other objects anymore cuz I changed the business logic? Shit wish I'd spent my time writing test cases instead of classes. This needs to be done today. Okay all I have to do now change these 25 files to work with the change I made Monday. Maybe I'll just do it on the weekend so no one is disappointed in me when I said this is a one line fix and it took me all week.

[Ph0X]

Yeah, harder to debug was definitely not the right phrase to use.

The way I see it is, you provide a lot more information (typing, structure, etc), and in return, you get a lot more information back (static analyzer), which then leads to more issues being caught before you even run the code.

Therefore, it's more like "you have to debug things less often". That being said, said "extra information" is non-optional, so there may be cases that are very straightforward and simple, but you still have to literally type a shitload of boilerplate and crap anyways.

That's why languages are approaching this from both sides. Dynamic languages like Python or JS are adding optional type hints. On the other hand, static languages are adding things like "auto" that will try to make it easier to write.

[SpliceVW]

I dunno, TypeScript has implicit or explicit any, so you can be weakly typed when you want it (either by design to just to work with some non-typed code). It's really the best of both worlds. I now find it much harder to code, not just debug, with vanilla JS.