91–99 of 99 posts
Earlier quoted context omitted.
What are the tradeoffs between records and structs?
The biggest difference is that Records are Immutable.
Earlier quoted context omitted.
> Code is rarely rewritten until it's at a point where it's horrible than it takes a massive engineering effort to rewrite and even this rewrite could be wrong. This is your problem, right here. Your instincts know when refractors and rewrites are appropriate. But if you live in a corporate culture where those things are never allowed to happen, of course you’re going to run into problems. Premature modularity is a p…
>This is your problem, right here. Nah. There's no problem here. This is the most common behavior in any place corporate or not. Humans resist change. However specifically for corporations, it is very very very rare for a company to allow a rewrite because of two reasons: First the company is often way to busy with creating features and solving problems then to do a code rewrite. Second it is in direct conflict with…
Its hard to say statements like that universally because it really depends on where you work (and have worked). There are plenty of places which make time to refactor along the way, in small and large ways. Its good engineering, and a healthy code base nets better long term outcomes for the business too. Business people care about the team's velocity (since programmers are expensive). And I'm disheartened you think its the norm but not all companies have MBAs telling software engineers how to do our jobs. (Eg, Google / Facebook / Netflix / Github / etc.)
> Do you have any evidence to back up your claim or is this just your opinion?
Its just my professional opinion, backed up by almost 30 years writing software at all sorts of companies and in all sorts of environments. But no, I wish we had quantitative evidence for this stuff. But there's a weird dearth of quantitative research around software engineering. We as an industry don't really know what we're doing yet. I'd love to read some studies on this stuff if you can find any.
But I'm very confident about what works best for me, from trying lots of things on solo projects. I'm way more productive when I throw something together quickly, iterate like mad on how it works internally, then tidy it up and modularize as I get more confident around the best way to structure the code. Whenever I modularize up front I basically always end up regretting my abstraction boundaries - and either have to rework them (which is expensive) or I leave them alone, and just ship vaguely mediocre code.
But if prematurely modularizing your code is the only way you can modularize anything at your workplace then - well, you do you. But I find that pretty sad.
Earlier quoted context omitted.
40+ years of programming experience here. The next step is to realise that MVC is just an example of events driven programming. An application is a state that “instantly” changes to the next state when an event happens. Multiple separate states (logging/UI/DB/remote/…) coordinate by reacting to events. The business logic is generating “this is now true” events. That’s it. There is nothing else to it.
That might be true for something where the phrase "business logic" is applicable. But in my niche (realtime audio software), there is underlying data in the system that changes over time independently of events. So there is "something else to it".
Earlier quoted context omitted.
"it doesn't really matter, you don't lose anything here" Except you do. It's harder to understand and less readable; and in a real life rather than made up example, addTwo is in some other module entirely and has side effects that are completely invisible (in most languages) when just looking at addThree, making debugging and understanding WTF is going on far harder. You mention "pure functional context", and yet thi…
>Except you do. It's harder to understand and less readable; and in a real life rather than made up example, addTwo is in some other module entirely and has side effects that are completely invisible (in most languages) when just looking at addThree, making debugging and understanding WTF is going on far harder. You don't lose anything from a hard structural standpoint. Readability and being harder to understand is a…
Lines of code != system's components.
It's why we don't split a 20 line function into twenty 2 line functions (where the first line is one of the original, and the second is the call to the next function), and no one would say that doing so has made the code more modular.
This is itself backed by the wikipedia link, 'In software design, modularity refers to a logical partitioning of the "software design" that allows complex software to be manageable for the purpose of implementation and maintenance. The logic of partitioning may be based on related functions, implementation considerations, data links, or other criteria'; what we have done by splitting up the code this way has not helped it be more manageable.
So no, by the definitions you yourself cited, splitting up the code does not translate to more modular code.
Earlier quoted context omitted.
>This is your problem, right here. Nah. There's no problem here. This is the most common behavior in any place corporate or not. Humans resist change. However specifically for corporations, it is very very very rare for a company to allow a rewrite because of two reasons: First the company is often way to busy with creating features and solving problems then to do a code rewrite. Second it is in direct conflict with…
> There's no problem here. This is the most common behavior in any place corporate or not. Its hard to say statements like that universally because it really depends on where you work (and have worked). There are plenty of places which make time to refactor along the way, in small and large ways. Its good engineering, and a healthy code base nets better long term outcomes for the business too. Business people care ab…
And I have worked in places where people know the exact formal definition of modularity and they modularize things correctly so such refactors never need to happen. I've worked and have experience in enough places to know that both a place where people understand true modularity and a place where people constantly refactor their designs on the regular are incredibly rare. My sample size is large enough for me to confidently say that your view point is highly highly inaccurate. Your experiences are in the minority of the minority along with the experience of working at any company that actually properly understands modularity. Understanding modularity is more of an individual thing.
The only time where I have been at a company that allows you to write shitty code and constantly refactor it are Big companies that have tons of low impact useless projects. Get on the project that is on the critical money path and all your luxuries of refactoring shitty code disappear because actual business realities influence the process.
>Whenever I modularize up front I basically always end up regretting my abstraction boundaries - and either have to rework them
This is because you lack knowledge about modularization and what should be a proper abstraction boundary. Almost know one knows what this properly is. You know the design pattern book by the GOF and every derivative book on that topic? Read it and then know that it's completely and utterly wrong. If you abstract things using traditional techniques and "art" and "experience" like this you ARE not making your code more modular.
>But if prematurely modularizing your code is the only way you can modularize anything at your workplace then - well, you do you. But I find that pretty sad.
You have a lot of confidence, and it's a subtle derogatory jab by saying your sad as if you're superior to me. Literally you're implying your sad that I can't rise to your level of "superiority." Get off your high horse. Have you ever thought of the possibility that you actually lack knowledge on something? That you've never actually properly abstracted things?
Earlier quoted context omitted.
>Except you do. It's harder to understand and less readable; and in a real life rather than made up example, addTwo is in some other module entirely and has side effects that are completely invisible (in most languages) when just looking at addThree, making debugging and understanding WTF is going on far harder. You don't lose anything from a hard structural standpoint. Readability and being harder to understand is a…
From the Wikipedia link you provide - "modularity is the degree to which a system's components may be separated and recombined" Lines of code != system's components. It's why we don't split a 20 line function into twenty 2 line functions (where the first line is one of the original, and the second is the call to the next function), and no one would say that doing so has made the code more modular. This is itself back…
Did I say this? No. Does this have anything to do with the conversation? No.
>It's why we don't split a 20 line function into twenty 2 line functions (where the first line is one of the original, and the second is the call to the next function), and no one would say that doing so has made the code more modular.
You think of logic as procedural lines of instructions. Procedural lines of instructions are not modular. If you think like this, none of your code is ever truly really modular. All code should be writable in one line. You split into several lines ONLY for readability, but your core logic should easily be isomorphic to one line code.
If your code doesn't share this isomorphism then none of your code is modular.
Inevitably you have to eventually address the procedural nature of the world in your code. When this case arises you have to abstract this all away to the smallest section of your code as possible.
>what we have done by splitting up the code this way has not helped it be more manageable.
Modularity and Manageability ARE TWO different words with two different definitions.
Wikipedia in this case is just being dumb and fuzzy with it's definitions. Right above your cited link it has an alternative definition that is in direct conflict with the one you stated. Modularity in modular programming is different from modularity in software? Come on. This is stupid.
Let's not play pedantic games here. Modularity and Managability are different. We know this. No need to play games. Combining the two into one thing is a lack of coherence. Be coherent.
When you take one thing and split it into two things. The two things are modules and thus more modular than the one thing. That is simple intuitive and clear.
Earlier quoted context omitted.
C# too, a very handy types https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
What are the tradeoffs between records and structs?
You can use structure types to design data-centric types that provide value equality and little or no behavior. But for relatively large data models, structure types have some disadvantages:
* They don't support inheritance.
* They're less efficient at determining value equality. For value types, the `ValueType.Equals` method uses reflection to find all fields. For records, the compiler generates the `Equals` method. In practice, the implementation of value equality in records is measurably faster.
* They use more memory in some scenarios, since every instance has a complete copy of all of the data. Record types are reference types, so a record instance contains only a reference to the data.Earlier quoted context omitted.
You're arguing that javascript doesn't succeed at being accessible to new programmers. I'm not arguing that. I'm saying that javascript nominally values about being accessible to new programmers. There are way more novice programmers using javascript than (almost?) any other language. This isn't an accident.
>This isn't an accident. No, it's because it's effectively the only option in the browser. If you are going to write front end code then you will end up writing JavaScript in some form or another. And being popular doesn't necessarily mean it is accessible nor simple. If it had been I doubt we would have seen Python becoming the dominant language in education.
In comparison, C++ does not optimize to be accessible to newcomers. C++ cares a lot more about compiled code running efficiently - as is evident from its insanely complex / powerful templating system. Its hard to learn, but its very powerful. Javascript and Python have nothing like that because that wouldn't align with the values of those languages.
Python values simple code that runs fast enough over complex code that runs super fast. C++ values code running fast enough, even if the code needs to be more difficult to write to achieve that speed.
Earlier quoted context omitted.
The "enterprise" programming culture which has emerged around Java doesn't impinge on all java code. But it is still a real thing. The fact that openjdk authors can rise above it and write clean, reusable Java code is obviously good. The fact that there is something that needs to be risen above is unfortunate. I think the same about Javascript, though the specifics are different. I've been writing JS for years, but I…
A language's core values is not determined by a small, vocal, subculture of its ecosystem. In Java's case, it was set early on to be a "blue collar" language [1]. If programmers fail to follow the spirit of the language then it will be awkward. "So, how does Java feel? Java feels playful and flexible. You can build things with it that are themselves flexible. Java feels deterministic. You feel like it’s going to do w…
Insane that anyone could say this with a straight face