Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't Be Afraid of Types

lmika.org

Post reply on HN
Print view View original

191–200 of 233 posts

Re: Don't Be Afraid of Types

#191

Post by bayindirh »

btreecat wrote: post #189
bayindirh wrote: post #157

Earlier quoted context omitted.

No, just putting the results in a set of objects as boxes and move them along. I don't use ORM layers. Just put the returning data from the DB directly into their neat boxes, string them along in a vector, and pass along. I also write my templated queries myself and talk with the server directly. No need to go "FizzBuzz Enterprise Edition" for a simple task.

When the data you need isn't entirely contained w/in those "neat boxes" you realize quickly the error was trying to force those "neat boxes" onto your data model.

Before starting to code any application, I tend to verify the ideas by first doing the design on my mind, then spending some time with a pen and paper, and maybe with some diagramming software. If I can't see the whole machinery in front of me, I don't start coding.

In your case, if the data is not fitting into neat boxes, it's not being forced into that in the first place. I select tools/features according to the problem at hand, not try to fit what I have into the problem at hand. If that requires a new language to learn, I'm down with that too. This is why I learnt Go, for example.

Sometimes the design stretches to its limits. If that happens, I stop, refactor and continue development. I call this outgrow/expand model.

It's not the fastest way to develop software, but it consistently gives me the simplest architecture to implement the requirements, with some wiggle room for the future.

For example, the latest tool I have written has broken the design I made in the beginning, because I overgrown what I designed (i.e. added more functionality than I anticipated). Now, I'm refactoring it, and will continue adding things after refactoring.

Every tool, every iteration brings learnt lessons, which are stored in a knowledge base.

Re: Don't Be Afraid of Types

#192

Post by Viliam1234 »

nottorp wrote: post #115
Viliam1234 wrote: post #91

Earlier quoted context omitted.

Interface are more fundamental to Java than classes. Sadly, at the beginning, many people came to Java from C/C++, and they did the thing we used to call "writing C/C++ code in Java".

I'm late to the Java party, I first did anything serious in it in 2009-10 and it was Android not "traditional" Java. So no idea about early Java's history. The interfaces is the only thing i loved from it.

One day I will write a Java project that won't contain a single "class" keyword (it will have interface, anonymous classes, and static methods), as a piece of art.

Re: Don't Be Afraid of Types

#193

Post by DeathArrow »

seanwilson wrote: post #159
samiv wrote: post #145

Earlier quoted context omitted.

I don't think this is what lasagna means. Lasagna is when you have your software organized in layers. In other words instead of having a big ball of mud where A calls B calls C calls A calls C calls B you have layers (like in lasagna) so that A calls B calls C and you keep your code base so that classes/modules/types that are in the lower layer do not depend on or know of the anything above them and the dependencies…

Not trying to be funny, but "Ravioli code" might be closer: https://stackoverflow.com/questions/2052017/ravioli-code-why... https://en.wikipedia.org/wiki/Spaghetti_code#Ravioli_code A related principle that I don't think is talked about enough is "locality": I'd rather have all the code about one feature in one file or close together, rather than it strewn across files where it's harder to read and understand as a wh…

There's Vertical Slice architecture that kind of does this. A feature is in a folder.

Re: Don't Be Afraid of Types

#194

Post by beluchin »

feoren wrote: post #131
DeathArrow wrote: post #70

People might be afraid of types because in OOP land there's the idea that types aren't mere containers for data. You have to use encapsulation, inheritance and polymorphism. Fields and properties shouldn't have public setters. You assign a value only through a method, otherwise you make the gods angry. You have gazillions of constructors, static, public, protected, private and internal. And you have gazillions of met…

Mostly agree, but there are methods that truly are best co-located with their (immutable) data. A good example is Point.Offset(deltaX, deltaY) which returns a new point relative to the callee. Why force that into a static class? There are plenty of examples where you want to use an abstraction over various immutable record types. Services vs. records is a false dichotomy and there is power in mixing the two. Yes, the…

> Static classes are fine for those functions if ...

> there is only one reasonable implementation of the function

this. In the absence of polymorphism, a static function is just fine. I am in the phase of avoiding object notation in preference of functional notation whenever possible. I leave OO notation to cases where, for example, there is polymorphism as the functional wrapper will add little to no value.

Re: Don't Be Afraid of Types

#195

Post by Kinrany »

jongjong wrote: post #24

I'm not a huge fan of types because they don't model the real world accurately. In the real world, most concepts which we describe with human language have many variations with optional properties and it's a pain and a waste of time to try to come up with labels to categorize each one... It induces people to believe that two similar concepts are distinct, when in fact, they are extremely similar and should share the…

"Modeling the real world" only makes sense when you're building a simulator of some kind.

Another similar approach is building a "digital twin" of something that is happening in the real world.

But very often the software is the only implementation, there's nothing to simulate.

Re: Don't Be Afraid of Types

#196

Post by beluchin »

svara wrote: post #105
efficax wrote: post #92

Earlier quoted context omitted.

it’s common to be imprecise and mix up the type and an instantiation of the type, and that’s all that is happening here

It's usually not just imprecision though, I've found that a lot of programmers fundamentally don't understand what types are and this confusion might be an example of that. Types are just a layer on top of your code that help enforce certain logical / mathematical properties of your code; those that your particular type system enables you to constrain. Most actual type systems are not powerful enough to allow you to…

Types are sets e.g. the Integer type is the set of all the integer values.

Re: Don't Be Afraid of Types

#197

Post by 9rx »

pjmlp wrote: post #55
9rx wrote: post #52

Earlier quoted context omitted.

> Then we are talking about distributed computing You must have a funny definition of distributed computing, then. OO never really caught on, probably because accepting "globs of undefined bytes" is kind of sucky, but we see some examples in the wild. Interface Builder is probably the best example of where we really leaned into OO, orienting a program's UI objects from externally defined messages. I'm not sure what b…

"Messages that originate outside of the program" is distributed computing, regardless of it is on the same computing node, or across the network. Multiple processes are involved, giving meaning to a byte stream. I am quite sure Interface Builder has enough Objective-C type definitions, as does Portable Distributed Objects. Additionally, those mapping definitions on the UI are nothing else than a type system powering…

> Multiple processes are involved, giving meaning to a byte stream.

Maybe in the case of Erlang, but that's a fairly unique case. Smalltalk[1], and by extension Objective-C, do not pass messages across processes.

Languages don't normally concern themselves with that kind of thing at all. You can build distributed computing on top of languages (pretty much any language), but that's not a trait of the language and way beyond the topic at hand.

[1] Which is what matters most as OO was literally defined by the design of Smalltalk.

Re: Don't Be Afraid of Types

#198

Post by 9rx »

DaiPlusPlus wrote: post #83
9rx wrote: post #19

Earlier quoted context omitted.

You can love conflicting things, but the basis of OO programming, that which makes it object-oriented and not just object-based, is message passing, which sees messages flow between objects for inspection. That is inherently runtime behaviour which is at odds with static type enforcement.

Swift has built-in support for actor-classes - which are strongly-typed too (not that it wasn't already easy-enough to define a self-driven actor class without the added syntactic-sugar) - I'm curious if you've tried that and how it fits into your notions of what OOP should be like.

I haven't used Swift since that addition, but last time I used it Swift had removed messages passing (unless you revert back to @objc mode). A look at actors does not suggest that message passing is back. What did I miss?

Re: Don't Be Afraid of Types

#199

Post by 9rx »

noduerme wrote: post #59
9rx wrote: post #42

Earlier quoted context omitted.

> The whole point of static typing is to ensure that runtime behavior is consistent with what gets passed. Right? More or less. While the whole point of object-oriented programming is that behaviour is defined at runtime through the passage of messages. The messages may originate from the very same codebase, but not necessarily. Consider something like NeXT's Interface Builder, which relied heavily on injecting messa…

For the way you think about and reference data (if you can ensure type safety). To me, the advantage of OO is to give data objects methods so you can extract or modify what you want, how you want. The confusion that seems to arise is when coders think that objects and classes should "do things" or "make things". Anything that can be static, should be static. And anything that can be instantiated directly, should be i…

> To me, the advantage of OO is to give data objects methods so you can extract or modify what you want, how you want.

Encapsulation is a trait of functional programming. You don't need OO to create 'objects' that offer 'methods' to extract or modify the encapsulated data.

OO is all about message passing; that is what sets it apart from other programming concepts. If you don't allow messages from external sources (thus fundamentally requiring dynamic runtime behaviour), you can do boring old static binding which is going to be way faster.

Re: Don't Be Afraid of Types

#200

Post by icedchai »

kirkhawley wrote: post #179
icedchai wrote: post #141

Earlier quoted context omitted.

OOP eventually degrades into "lasagna" (a play on "spaghetti code".) Layers and layers of complexity like you describe. Once you have enough "layers" it becomes almost impossible to follow what is actually happening.

ALL code eventually degrades into lasagna.

This is sadly true!
Post reply on HN