Plagiarism is theft because it does take something away from the original author (attribution). Plagiarism and piracy are different concepts. Making a copy and forking the code is not what they did wrong, that part was authorized. Deleting the author's name and pretending it was their original work is the issue.
I don't consider it productive to be personal about technical topics. It's best to divorce yourself and the other party from the issue to limit as much bias as possible. You don't need to worry about the good-faithness of an objective, egalitarian discussion. It's never truly objective, but you can at least catch yourself saying things like "I might think less of you as a developer" and recognize that's a preconceived notion. In some cases, it may be turn out to be accurate, but it's definitely not always. Dynamically typed languages have had an important role historically in software. We should not categorically denounce people who prefer it as lesser developers. I also generally prefer static types.
Some prejudices are rational. To paraphrase, it would take an enormous amount of prior trust and respect before I even humour someone trying me to convince me the sky is green with a straight face.
Some issues are settled enough that there is no need to discus them any further. It is okay to automatically mark people on the wrong side of such issues… let’s say ill-informed.
Static typing, I believe, is close to being one of those issues.
I think this is OK as long as you keep your mind open to situations that you have not considered.
Imagine someone is working in a relatively niche new programming language ecosystem which is dynamically typed, allowing the language to have some richness that modern type systems don't support. I don't have an example because I don't know of any such language in 2023... BUT back in the 70s and 80s this would have been Lisp. Lisp couldn't have been strictly typed back then because, AFAICT, type systems hadn't advanced enough to express the sort of metaprogramming that made Lisp unique and awesome. This was at a time when most popular languages were strictly typed.
I would hope that you would keep your mind open to whatever that maps to in the 2020s.
Now, if someone says "I like JS over TS because types are annoying and slow me down", then yeah, I don't have much patience for that either.
You make points that seem great to me although I know almost nothing about Lisp or 20th century programming.
The thing is, I've yet to encounter a single instance of such an argument today. Every single time it ends up being "I like JS over TS because types are annoying and slow me down". It hadn't even occurred to me that laziness and sloppiness weren't the the only reasons to write in dynamically typed language.
I suppose what I'm saying is I'm quite interested in seeing what kind of evolution some dynamically typed language could offer in the future. Although with no signs of its coming, I'm going to stick to TS because it's objectively better for anything but very small projects.
TS is an interesting example to pick when trying to argue that types are better. You have all the same downsides people pick on when arguing against strong, static typing, but since the type system isn't sound you still can't rely on the input to a function being the type you expect (and the problem is worse anywhere you inevitably interact at least a little with the JS world outside your TS bubble).
At best it's a form of documentation that enables some simple linting rules and a bit of jump-to-definition magic. Like, that's a benefit (mostly -- I tend to think that type signatures implying more guarantees than they provide is a recipe for inadvertently relying on falsehoods), but it's not as clear-cut of a win as you see in other statics/dynamic tradeoffs.
> The thing is, I've yet to encounter a single instance of such an argument today.
I don't mean to be unnecessarily contentious, but isn't that the point of undiscovered territory?
We haven't encountered it yet, when we do then as awareness grows that pattern, idiom, theorem or concept will be picked up by mainstream statically typed languages.
It's enough to believe that the properties of (for example) JavaScript might lead to an as yet undiscovered pattern that is not possible in current statically typed languages.
Yes sure, it's always possible. My narrow experience leads me to believe, however, that some necessary threshold hasn't been crossed yet. And there's vanishingly little chance that I personally will be participating in such a revolution. Therefore from my perspective, it isn't happening yet and I can only wait to see if it does - meanwhile, I'm on the opposite side.
Imagine working on a networked system that uses types to make it impossible to express operations that violate data security and integrity constraints, and where such constraints control whether data is allowed to be read or written from or to a given endpoint. Imagine further that the types governing permission to read or write depend on environmental state that can change at any time--for example, as soon as a specific person changes roles, the set of ports they are allowed to read and write changes.
The type system enforces those permissions: writing to an impermissible destination is a type error. The types applicable to an entity are not necessarily knowable at compile time; some of them might change at any time.
I had a job working on such a system. It supported a type system implemented in Haskell with both static and dynamic type disciplines, where values were tagged with base types designed to be checked dynamically in hardware.
Was the programming language dynamically typed? Yes. Was the programming language statically typed? Yes.
Python fits that niche now. Half the way tensorflow, et al work is by doing brain surgery on the AST in a way that resembles hey day Lisp's 'even the code is just s-expressions, process it as much as you want to the point of 80/20ing your way to your own compiler'.
It sounds like you have an implicit prejudice against those who do not "keep [their] mind open to situations that [they] have not considered", since the way you phrased your concern is moral in nature. You see it as morally bad not to have an open mind in that way.
Yeah, sure, I do in fact think it is virtuous to be aware that we don't always have complete information and that we should be willing to revise our opinions when new information is encountered. Is that controversial?
No, no, not controversial. I intended to make it easier to understand the point by demonstrating for the more literal-minded that using moral language sets up two halves of a dichotomy, one preferred to the other, so that such prejudices needn't be personal but rather merely moral. The difference is of course that which side of a moral dichotomy is a choice that can be reversed (e.g. making an effort to open the mind) while personal matters are immutable in those people.
If your prejudice prevents you from having a conversation with Matz or Jose Valim or Van Rossom or the creators of Julia about software development, you may want to reconsider your prejudice as a hard and fast rule.
You can't honestly believe no one who likes to develop in a dynamically typed language has nothing interesting to say about software development?
I can't (or, more accurately, don't) believe that, but I can certainly believe they have nothing interesting to say about the topic of static vs dynamic typing.
An open mind is like a fortress with its gates unbarred and unguarded.
It is both useful and allowed to have a certain level of belief that won’t be crossed without heavy effort. The OP didn’t even say they were closed to the conversation completely, but that a random person with no pre built trust isn’t going to get the time of day from them to rehash the same settled argument.
Doesn't everyone have those? Like, I'm unlikely to really engage with someone about my health unless they're a doctor or otherwise have some area of expertise. Or if it's just a casual, friendly conversation, to kill some time.
Everyone has biases. But you aren't describing a bias, you are describing a refusal to engage with people below you. Speak for yourself, I don't have that.
We’re all humans and life is very complicated with many facets. If we all looked hard enough I’m sure we could find a person you’d refuse to engage in a debate with over their “thing.”
But that wouldn’t be a wise use of time in my opinion. And that’s what they’re ultimately driving at: we all have limited time to expend, so do it in things that matter to you. I believe “matters to you” is a bias.
"Below you" is a bit of an exaggeration, I think. I said that I might think less of someone as a software engineer if they express an opinion that I think is particularly bad. Hardly egregious, in my opinion. I also might not - it frankly depends a lot on the situation.
These people opinions are based on bad information.
Beliefs inform decisions and other beliefs
I disagree with them on a huge number of fundamental things in software. Most of their fundaments are claims with no evidence. Due to that, I simply do not care about what they have to say most of the time.
Python got type hints bolted on. A type system for Elixir is being worked on. Dynamic typing was a prerequisite for Erlang to enable hot-code-reloading. Julia is can be typed for an extra speedup. Stripe built a type checker for Ruby called Sorbet.
I'd love a dynamically typed scripting language with the following two properties: no "import" mechanism to split code over multiple files, and no way to execute more than (say) 256 lines of at most 128 bytes each in the file.
Dynamic types are nice for quick & short scripts, and actively detrimental for anything long and complex. Why not enforce that? As soon as it gets so long it doesn't run you know it's time to rewrite in a statically typed language. Instead all existing scripting languages allow unlimited growth in code size, making it easy for programs to grow beyond the point where the language is useful.
> Dynamic types are nice for quick & short scripts
A long list of big products and companies are there to disagree with this. I am not saying that dynamic is better or worse. But saying that dynamic languages are only good for quick short scripts is a wrong generalization that has not one exception but many exceptions.
> To paraphrase, it would take an enormous amount of prior trust and respect before I even humour someone trying me to convince me the sky is green with a straight face.
Don't venture into tornado country; your doubt may be your downfall.
> To paraphrase, it would take an enormous amount of prior trust and respect before I even humour someone trying me to convince me the sky is green with a straight face.
But people regularly say the sky is blue, and it's clear as day that it's not when the earth has turned and your side isn't facing the sun.
I don't think that's a statement that most would agree with. What is the sky? Sure the atmosphere can be called blue, but the sky is what's visually above the earth. At night, that's black space. The atmosphere is mostly transparent at night.
The sky isn’t inherently blue. It’s essentially colorless.
Only due to Rayleigh scattering do we perceive it as blue, but that’s not due to the absorption and reflection of different wavelengths we associate with innate color. Note that the color changes depending on the angle of the sun, even to the point that it’s purple and red at a few times during the day.
I explicitly said "as a developer" because it's not a personal judgment. You can be a good person and also have a terrible take as a software engineer.
> We should not categorically denounce people who prefer it as lesser developers
I don't think you've justified this point. I'm comfortable with my position on this.
What you say is true, but it’s also true that the person you are replying specifically made their remarks about productivity - you’re both talking about what is best at work.
It seems reasonable to argue that statements that you won’t even discuss X any more and would rather judge the person as less competent professionally are unproductive. Not saying I agree, btw. But it does seem like a pretty basic point. One of you is talking about preserving your sanity and the other about output. It’s not necessarily a disagreement even.
I still think it's reasonable to argue that's not a "productive" approach, but like I said, that's not my own opinion, I just think it's a reasonable argument.
Again, I don't mean "personal" in the sense that you are making a statement about someone's worth as a person. It's "personal" because you extrapolate information about an individual person's technical skills from a single opinion than you have any real factual justification to do so. People will always find ways to defy your preconceived notions.
I don't necessarily think it makes someone a "lesser developer" if they prefer untyped languages, but I DO think they've either had to maintain anything long term or it stayed relatively small.
Whether that makes them lesser or not isn't really for me to say, but I can say I'm definitely on board with the idea that types increase productivity the longer a system is maintained. Unless used poorly, types don't automatically mean you use them well, but they make it a hell of a lot easier to do the right thing.
I think you're being a bit too sensitive, and it's not personal. Someone is espousing a (bad) technical opinion about their field of work, it's not unreasonable to say you respect them less in their field of work. That's not personal.
It's like if you met a builder who refused to use a hammer and insisted on bashing nails in with the back of their drill. It's not "personal" to say you'd respect that person less as a builder, regardless of how much you'd enjoy having a drink with them.
It is "personal" if you attach someone's technical opinion to broader implications about their own competence. If you disagree with a technical opinion, say so and move on, there is no reason to even discuss someone's own personal skillset, experience, or value as a developer. It's a silly fallacy to automatically label people who disagree with you as incompetent. All it does is foster bias and stifle actual discussion. The responses to this post are evidence that this is not as cut and dry as the original posts suggests, so I suggest we try our best not to cover our ears and embrace tribalism just because we think less of someone's opinion. I don't think I'm being oversensitive by saying this is unproductive dogmatism. It is my honest opinion, yet I do not extrapolate to mean anything about the proponents' value as a developer. Unconscious bias is a pervasive problem for everyone, especially when it comes to binary holy wars like static vs. dynamic types. This is more akin to a builder who uses a nail gun rather than a hammer. Hammer enthusiasts can either acknowledge that both approaches have tradeoffs or they can petulantly insist that people who don't use their methods aren't "real" builders.
I'm sorry but this is a discussion about their competence. You can't separate someone's opinions on technical topics from their competence in the very technical field you're discussing. If a cartographer has the "opinion" that the world is flat then that directly speaks to their competence as a cartographer.
For starters, "the world is flat" is falsifiable and trivially disproven with evidence. "Dynamic types are better" is neither of these. If you're going to pin someone's professional value to a single technical opinion, you should at least be able to back it up with data.
Nah, someone opposed to typing is either a shit developer and/or a madman who codes too clever by half mad shenanigans that take advantage of the lack of strong typing. I wouldn't want to have to maintain or depend on code written by either.
For the very rare cases where a lack of strong typing is needed, most languages with strong typing offer ways to handle that (i.e. the Object and Dynamic types in C#)
As someone who usually prefers JavaScript over TypeScript but has used many typed languages over the years and generally finds then easier to work with in a way, I agree that one should not pre-judge based on something like that.
But he's just being honest. Many developers have been making that judgement for many months or even years.
Disliking async/await does not make someone "generally bad at programming". This is a childish ad-hominem mindset that has no place in technical debates. Rust's decision to adopt async/await over green threads was intended to keep the runtime lean, not because it is an inherently better abstraction. Java certainly could have async/await syntactic sugar around its existing futures api, but project loom has greater ambitions by retrofitting asynchronous IO onto the existing thread api. The authors are certainly not "simply wrong" for this decision.
Sure, it is "childish and ad-hominem", it is also efficient and usually works. Also, non-async/await solutions for concurrency and asynchrony result in a more verbose, complex and bloated syntax, having to invent fancy terms like "structured concurrency" for use cases which in C# are simply expressed by awaiting the task at the point of its consumption and not declaration (no special methods required) or in Rust via simple, albeit for a different scenario, join!().
var user = try alloc.create(@Frame(service.GetUser));
user.* = async service.GetUser(id);
defer alloc.destroy(user);
var promos = try alloc.create(@Frame(service.GetPromotions));
promos.* = async service.GetPromotions(category);
defer alloc.destroy(promos);
var eligible = GetEligibility(await user.*, await promos.*);
but the claimed difference is not present in this code. It is that GetUser and GetPromotions do not themselves know whether they are async. The author of service is able to just take some readers and writers or some types or objects implementing some protocols and use them, then service's methods inherit the async-ness of its dependencies.
async/await and structured concurrency are two different things, Swift has an async/await syntax but is still structured concurrency.
The point of async/await is that it converts your function into a reentrant state machine (in a different way than compiling a sync function already turned it into a state machine.) The problem with the usual design is that it uses futures, which are bad because they have dynamic lifetimes.
I think your disagreements are valid, but I don't think it is fair to say this is an amateurish take or infer the author's level of experience. Your example of unnecessary inheritance hierarchies (which I have also faced many times in real world scenarios) may even be a symptom of exactly what the author is saying: what you might call a "bad fitting abstraction" the author would just call "bad code". The implementation details of how code gets shared (composition vs inheritance) is a subtle but still vital consideration to the cost benefit analysis. The author is observing that it might be misleading or dangerous advice to urge developers to choose duplication just because issues with abstraction have been historically observed, which I completely agree with and do not consider myself to be an amateur. I also agree with you and other posts that the author fails to mention the (exponentially higher) costs of abstraction boundaries that also span human organizational boundaries.
Bun is apparently targeting September 7th for a 1.0 release. I also have concerns about delivering a stable api using a language that doesn't have one yet.
Tbh I've had the same issue delivering my own 1.x software with 0.x dependencies and my argument has always been that it's my problem, not the client's, so "do not worry". Being realistic, no sw offers any guarantees and Zig's 1.0 stability is more of a "contract" than a "guarantee".
>That 'balance' is not for everyone - but crucially it is what some people want
I've never seen anyone that could sustain an 80+ hour per week grind and make it out without severe personal issues (whether they are willing to acknowledge it or not). I've seen many, many incredibly talented people burn out and suffer permanent health or career damage to hit their short-term goals. I personally know an otherwise healthy 30 year old swe who had a stress related heart attack. It may be what some people want but you can't grind your way out of being a human.
Is there a way to disable arbitrary I/O in macros? I would like to use this feature to compute lookup tables and inline the results of pure functions, but I really really do not want my bundler making arbitrary http calls or other sorts of nondeterminism. I need to be able to reproduce my bundles confidently.
In this case SignupRequest is your contract representation, Account is your storage representation, and the "backend code path" is the transformer/napping layer.
>I don't have two representations of the same object. Rather I have two different object
Exactly! Your api contract and your storage are ALWAYS two different objects, because they serve two different concerns. Sometimes by coincidence they can share the same shape but there's no reason that they need to be coupled together and impossible to change independently, other than the fear of inconvenient "boilerplate" mapping logic. By doing this up front, and not even letting it enter your data model, you create a formal abstraction boundary; it's reserving the right to change two pieces of data independently. Also, mapping/transformation logic can often just be simple, pure, total functions; which are trivial test and maintain compared to anything that touches I/O.
> Exactly! Your api contract and your storage are ALWAYS two different objects
Not really. I have request objects for everything. "Search" is a request object. List pagination is a request object.
Every function exposed through the RPC API takes a request object and returns a response object.
The response object is often just a collection of objects straight from "the database".
A response to a paginated list request will contain a list of objects straight from the database, in addition to some metadata about the pagination (names: current page number, total page count).
The cruicial part is there's no "transformation" of data as it goes out from the database into the UI. There's some aggregation and grouping (an outer object that contains multiple objects), but that's about it.
Again though there's a subtlty: some transformations do occur, but they don't occur on the path from the storage to the UI. Instead, everytime I store a complex object, I also derive a "simple" version of the object and store it too.
When you request a list of objects, you get the "simple" version, and the UI displays them in summary format. When the user clicks one of them items on the list to see more details about it, the backend sends the "full" object.
Notice the underlying principle: the UI flow dictates how the storage layer stores objects.
This is the anti-thesis to the common wisdom, where the storage layer does not care about the UI, and it's the job of the intermediate layer to transform data for the needs of the UI.
Yes really. The fact that you can "often just return an object straight from the database" and have it fulfill the functional requirements of your client is just a coincidence, or more likely it's an invarient that you have decided to enforce. What people have discovered (usually very painfully) is that unavoidable breaking changes to either your client representation or storage representation are bound to happen, and when they do if you haven't separated these concerns this will have a ripple effect through the entire application. This may be fine. If your applications are tiny or downtime is okay, then you likely won't care about this. But to casually dismiss this advice as simply always being overcomplicated and overengineered is a grave oversimplification that you may regret someday. Many of the topics in this post fall into this category - people do it for a good reason, and you might not need it, but everything is a tradeoff and "I'm just going to do the stupid simple thing" is not the silver bullet.
> Also, mapping/transformation logic can often just be simple, pure, total functions
I find this is never the case - usually for the exact reason you inadvertently sold as some kind of "benefit": "it's reserving the right to change two pieces of data independently" - because when you need to map from, say `SignupRequest` to an `SavedAccount` object you'll encounter data-members required by `SavedAccount` which cannot be sourced from the `SignupRequest` object - for example, supposing the UX people come to us and say we need to split-up the registration form into 2 pages, such that most fields are still on page 1, but the password boxes are on page 2. Now you need to deal with how to safely persist data from page 1 for use in page 2 (so using hidden HTML inputs between pages won't work because that requires POST requests to work, but both pages should be able to be intiially-requested with a GET request.
