Programming Languages

1156 readers

7 users here now

Hello!

This is the current Lemmy equivalent of https://www.reddit.com/r/ProgrammingLanguages/.

The content and rules are the same here as they are over there. Taken directly from the /r/ProgrammingLanguages overview:

This community is dedicated to the theory, design and implementation of programming languages.

Be nice to each other. Flame wars and rants are not welcomed. Please also put some effort into your post.

This isn't the right place to ask questions such as "What language should I use for X", "what language should I learn", and "what's your favorite language". Such questions should be posted in /c/learn_programming or /c/programming.

This is the right place for posts like the following:

"Check out this new language I've been working on!"
"Here's a blog post on how I implemented static type checking into this compiler"
"I want to write a compiler, where do I start?"
"How does the Java compiler work? How does it handle forward declarations/imports/targeting multiple platforms/?"
"How should I test my compiler? How are other compilers and interpreters like gcc, Java, and python tested?"
"What are the pros/cons of ?"
"Compare and contrast vs. "
"Confused about the semantics of this language"
"Proceedings from PLDI / OOPSLA / ICFP / "

See /r/ProgrammingLanguages for specific examples

Related online communities

founded 1 year ago

MODERATORS

armchair_progamer

Why Static Languages Suffer From Complexity (and type-safe printf implementation without macros) (hirrolot.github.io)

submitted 1 year ago by [email protected] to c/programming_languages

7 comments fedilink hide all child comments

I think, especially in programming language communities, that there tends to be a preference towards making a static language for their compile time guarantees, and this is a pretty concrete counterargument as to why people find dynamic languages "easier to program in"

you are viewing a single comment's thread
view the rest of the comments

[–] philluminati 2 points 1 year ago* (last edited 1 year ago) (1 children)

Very long and a little bit of tricky read but certainly interesting observations. As a Scala developer I actually see the problem with static vs dynamic code all the time. A desire to force everything into the static type system so errors are found early is commemerable, but even in places it doesn't necessarily make sense. A common example is taking user input and shoving it in a cats NonEmptyList. A type which exists soley so that calling .head won't cause an exception. Apparently using .headOption is a deal breaker. The other place is the desire to serialise classes into json structures automatically. This is again commendable and makes programming much easier in some constraints, but it then remanifests as a problem when you realise that internal types and external types need to diverge in some way. At runtime it's easy to change mappings between two arbitrary structures and you can inspect the data, but trying to do it via the limited language exposed by a macro is painful.

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

I agree with your second point but not the first, because presumably the code processing user input has a better idea of what to do if the input is invalid because it is an empty list then some other random part of your program that requires a non-empty list but finds out that it has been given an empty list instead.