this post was submitted on 06 Jul 2023
64 points (100.0% liked)

Programming

17111 readers
261 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 1 year ago
MODERATORS
top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 21 points 1 year ago (8 children)

Overall I agree with what the author says, though I have a few further thoughts:

One might argue that writing types are time consuming, and the bugs are not an issue when programmer can cover those cases with automated tests.

These two arguments contradict each other and together are an argument for static typing, not against. Which just shows how weak these arguments are.

but a more powerful type of inference that can actually infer the whole type of a function by analyzing the body of the function.

This bit I am not convinced by. Inferring the API of a function from its body makes it harder to see breaking changes when you refactor the body. It can be useful for internal private helpers, but IMO public APIs should be explicit about their signature.

Functional Programming

I would go one step further here. It should support OOP and procedural paradigms as well. No single programming paradigm is best suited to all problems. Sometimes a mixed approach is best. Any language that heavily leans oneway at the expense of the others limits itself to the problems it can best solve. I do admit the far too many languages lean too much towards OOP at the expense of functional style.

So it is easy to push for a functional style over OOP in new languages. But I would be weary of purely functional language as well.

[–] [email protected] 3 points 1 year ago (1 children)

These two arguments contradict each other and together are an argument for static typing, not against. Which just shows how weak these arguments are.

The way I read it, he wasn't suggesting that was a good argument at all. He was just explaining what he believes dynamic type enthusiasts say.

This bit I am not convinced by. Inferring the API of a function from its body makes it harder to see breaking changes when you refactor the body. It can be useful for internal private helpers, but IMO public APIs should be explicit about their signature.

Well, in F# at least, this inference is the default. However, anybody can still fully type out the function signature. I think I get what you are saying, but in the case of a public API or interfaces the programmer can simply just add the type specifications.

I would go one step further here. It should support OOP and procedural paradigms as well.

Yea I somewhat agree with this. Though I mostly abhor OOP, it taken in small doses can be good. And procedural programming is always invaluable of course.

[–] [email protected] 3 points 1 year ago

The way I read it, he wasn’t suggesting that was a good argument at all. He was just explaining what he believes dynamic type enthusiasts say.

Oh I read it the same way. I was just pointing out how much those two arguments contradict each other and that alone is almost enough of an argument without the extra ones the author gave. Though at the same time they are a bit of a straw man.

Well, in F# at least, this inference is the default. However, anybody can still fully type out the function signature. I think I get what you are saying, but in the case of a public API or interfaces the programmer can simply just add the type specifications.

But the problem with this being the default is most people wont go through the extra steps involved when they dont need to - which means you cannot really benefit from it most of the time. And the author implies that inferred types from bodies are always (or almost) the better option - which I disagree with.

Though I mostly abhor OOP, it taken in small doses can be good

Do you though? Or do you abhor inheritance. There are a lot of good ideas from OOP style code if you ignore inheritance (which was not originally part of the definition of OOP, in fact the original definition was very similar to some traits of function styles). It was only in later years and more modern times that OOP and inheritance was intertwined and IMO as a style it still has a lot to offer if you drop that one anti-feature.

load more comments (7 replies)
[–] [email protected] 11 points 1 year ago (1 children)

With regards to immutability and pure functions, I don't really care where the language falls on the scale the author defined so long as there is a way to easily express deeply immutable objects and pure functions. There are a ton of benefits of those two things and a lot of optimizations and assumptions that can be made with them. So I don't really care if everything is immutable by default but just being able to tell the compiler/runtime "Hey listen, this thing won't change ever, got it? So go crazy with passing it to threads and stuff" or "This function will 100% definitely return the same value if given the same input so if it takes a long time you can cache the result if you're able to." both seem very appealing.

[–] abhibeckert 1 points 1 year ago

Hey listen, this thing won’t change ever, got it? So go crazy with passing it to threads and stuff

I don't really care about that - none of the code I write is compute bound anyway. The CPU is generally twiddling it's thumbs idle for millions of cycles with occasional brief moments of activity when the SSD finally responds to the read operation that was requested an eternity ago. Or worse, it might be waiting on a network request.

I want immutability so I can, for example, make a copy of it and know my copy will always be the same as the original. In other words I want to be able to do my own caching/etc (possibly to avoid SSD access).

[–] [email protected] 8 points 1 year ago (1 children)

I've been liking Go. Reminds me of Python without the risk of filling my Linux install with dependencies.

[–] [email protected] 2 points 1 year ago

So if there's a non-breaking security update of a dependency, all go apps depending on it need to be recompiled and relinked?

There's no way to link dynamically?

[–] pimterry 7 points 1 year ago

TypeScript has become my go-to general-purpose option. Between Node.js & the web you can build anything (and share code between all these different domains), the JS ecosystem is huge so there's existing libraries & examples for everything, it gives you a good balance between productivity & performance (much faster to run than Python, much faster to write than Rust), and proper typing solves the rough edges of JavaScript without being so strict that you have to fight it.

I work with Kotlin, Rust, and Bash for various other specific things (e.g. Android apps, very low-level/high-performance code, and widely-compatible scripting) but 9 times out of 10 I'd reach for TypeScript if there isn't a special reason.

[–] [email protected] 7 points 1 year ago* (last edited 1 year ago)

In my opinion, it depends on your goals and scope. If memory manipulation (Probably not the correct words), and/or every bit of performance matters, or it has a large scope, then one would pick Rust/C-lang. If development time and scope is small, something like Python is better.

Source: I used C++, C#, Python, and I use G'MIC (language very much geared for raster graphics processing).

[–] KelvinDegrees 7 points 1 year ago (1 children)

I've become a big proponent of static typing and the functional programming paradigm, both of which solve the problem of figuring out what you're looking at.

With OOP and side effects you can receive a variable but still not know what it really is, is it modified somewhere before or after that you missed? Is it passed deep into nested functions that modify it? Who knows! With pure functions that goes away completely, you can easily inspect what goes into it.

Static typing also solves, among many other problems, this same issue. I've written a good deal of python, and anytime I go from rust, my current love affair, back to python I end up needing to take a break and go to my dog for emotional support. I've tried using mypy for static type analysis, I still use it, but it's very far from perfect; not least because many of the scientific libraries I use don't implement static type hints and are in fact written in such a way that implementing them would be difficult or nonsensical in some instances. It's a complete nightmare. The only solution would be every one of these libraries rewriting themselves, so not likely.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

As someone who works extensively in Java, I agree, side-effects are tough and should be avoided in OOP. A lot of teams are moving toward more of an immutable object pattern as a standard, but its tough to enforce and adds a lot to the verbosity of the language.

Rust is a language I am currently in the process of learning and it seems great! 👍

[–] [email protected] 6 points 1 year ago (1 children)

Rust is my goto language today. It dips its toes into a bit of everything I like doing (webdev, cli apps, etc) and I feel comfortable with it. I haven’t found a project where Rust would hold me back yet, but I’m assuming I will eventually.

[–] Pyroglyph 2 points 1 year ago (1 children)

I’m assuming I will eventually.

I somewhat doubt that. To me, it feels like Rust has consistently been getting better and better over the years with no end in sight! That said, I would be interested to hear any differing opinions.

[–] [email protected] 2 points 1 year ago (1 children)

Nothing is going to be the best at everything. Been programming for a long time and it’s a general truism that every cool new thing comes with a real trade off. I just haven’t found Rust’s yet.

Maybe I get lucky and the trade off is just all the weird community drama.

load more comments (1 replies)
[–] colonial 5 points 1 year ago* (last edited 1 year ago) (1 children)

I want to say Rust, but for some stuff it's probably very overkill. I love it, but there's a reason we don't use CPP for everything. (WASM may change things here but IDK)

Swift would be an excellent candidate for the title of "simpler Rust," but unfortunately it's doomed to rot in Apple's walled garden for all eternity.

Honestly, I would say TS (which I hate, but it's indispensable for many things) or any JVM/NET language (Kotlin, C#, both are good)

[–] [email protected] 2 points 1 year ago

Does it matter if it is overkill as long as it doesn't slow you down too much.

I love it

Is a great reason to learn and use a language

which I hate

Is a great reason to avoid using it.

If you don't enjoy the tools you use them you are going to be far less motivated to work on things. Which will kill off a lot of projects.

There are something that TS is better at, but there are also a lot of things that rust is better at. Each languages haves different strengths and weaknesses. IMO both rust and TS are both fine general purpose languages to learn. Personally I would pick rust for most things though and would definitely favour it if I could only learn one language.

[–] [email protected] 4 points 1 year ago

I agree on basically all points. Great article, nicely explained.

[–] [email protected] 4 points 1 year ago (2 children)
[–] [email protected] 2 points 1 year ago

The language itself certainly has a nice appeal, but I just don't like the JVM and inheritance styled OOP... it's personal... haha

[–] [email protected] 1 points 1 year ago

Started Kotlin at my current job, coming from .NET. I'm impressed by Kotlin!

[–] [email protected] 4 points 1 year ago* (last edited 1 year ago) (1 children)

my opinion is a good language needs these qualities. Portable, Safe, Fast, Easy.

which seems to be similar to the author of the article. the language I have found to match the criteria the most is the D programming Language, its so mediocre in every area.

3 separate compilers, gcc llvm and mars backends. can be as safe as you want it to be, with constructs for purity, GC, and contracts built in. can be as fast as you want it to be it is a systems language and gives you all the necessary tools to go down to C level or below with a good in line assembly, but generally the idiomatic code is fast enough you dont need to go to the C level.

it is also very easy, you have a lot of C libraries and D libraries you can use and with a built in C compiler (currently beta) you can import C libraries easier, it also has a similar syntax to C so its very easy to rewrite C code in D, it has an optional GC so if you are going for max performance you can beta test algorithms quickly using the GC and when you are ready for max performance you can do it all manually, or you can use the feature to test what is using the GC so you can avoid the GC in loops, I did this in a game recently, I used the GC to setup all memory at the beginning and turned off the GC so I would never use it in a loop,

another nice feature is functional features that make the language cleaner to write. I dont think this approach of being perfectly mediocre is necessarily the best but at least on paper its very good, and in practice there have been companies (specifically Weka Digital) that swear by the approach, they can use one language for both testing out ideas and the final product. but again in a lot of cases you dont want a language that is good at everything you want one that is good for your use case.

also the article was very interesting, language design fascinates me and the article was a good read really enjoyed it. currently planning on learning Haskell and Zig soon should be fun to compare these once I am comfortable with them.

[–] [email protected] 3 points 1 year ago (1 children)

I so wish that D would have taken off :/

I used it at the time of the library split (there was a split in the community regarding the standard library, where Tango was the alternative). The compile time features of D were fantastic and they are still unmatched; as an example: For OpenGL (back then OpenGL 2.x) I could define the vertex attributes and had them checked at compile time when I started to fill the data with glMap! D templates and compile time code generation are on a whole new level, although it made tooling more difficult. If you know constexpr in C++, then this is nothing compared to what D has to offer.

[–] [email protected] 2 points 1 year ago

yeah it has a really good blend of features, I think that it could have saved quite a few large companies a lot of money, as well, like facebook who keep re programming stuff, with D they could have used the same language and they would have very rarely re programmed anything, and when they did they would have been able to re use some code. so I am quite surprised it didnt catch on, but it did have a few problems, one being it got relatively popular too quick before it could mature. GC problems, and being too experimental, a very good language is hidden behind a lot of features.

[–] [email protected] 3 points 1 year ago (1 children)

Typescript. Runs everywhere. Very active community. It’s the modern day Java.

[–] [email protected] 4 points 1 year ago (1 children)

I don't know I really hate when jumping to definitions in libraries, I often just land in the "typings" file. I also think that the type-system is often incoherent, has some weird side-effects and often leads to overengineering your typings... I just generally avoid Javascript based languages (which unfortunately is not really possible in frontend...)

[–] [email protected] 1 points 1 year ago (1 children)

Typescript has many shortcomings. About every language does. But it’s an undeniable very strong benefit that you can code the front and backend with it easily. It runs everywhere. It’s reasonably fast, for aws lambdas I found it had really good cold start time. I suspect because node is built on V8 which is highly optimized to get code running asap.

That accessibility and versatility makes it in my opinion the best general purpose language right now.

[–] [email protected] 2 points 1 year ago (3 children)

In backend I'm absolutely happy I can avoid it, there are more solid and more performant languages. I just can't program in the style I want without loosing massive performance in java/typescript, like in a functional composable style, it results in a mass of allocations, I hate it (because it looks cleaner and is a better architecture IMHO). Rust does a much better job here... I'm also not a huge fan of the type-system, it's super flexible, but has some incoherence, you tend to overengineer your types, no real ergonomic algebraic data types etc. It also has so many weird design decisions (e.g. prototypal inheritance) I don't understand and don't like...

I think Rust comes probably from the other direction, I can soon write my frontend in Rust without having much ergonomic loss (lets be honest, UI frameworks are currently more "solid(js)" in typescript than Rust, but I think that may change in the future...)

load more comments (3 replies)
load more comments
view more: next ›