Hacker News Reader

Comment by tluyben2 | Hacker News Reader

It is probably/definitely me but I watched the long video and did not learn anything and then read the GitHub example for a few minutes and got it. I have a hard time understanding why ‘young people’ (or maybe all people outside myself as it sometimes feels) enjoy videos; text is so much faster for everything but learning how to render a wall (stuff with your hands). Then again, I never went to lectures in uni vs reading books, papers and syllabi; the latter I found to be much faster.

Anyway, congrats with the project; it seems pretty common sense idea wise so it is nice but cannot see many people jumping through the hoops and adopt it; people are too opinionated (including me).

View on HN

Thanks for the feedback, and I'm glad to hear that you understood the concept from the text documentation.

We decided to include both videos and text in the documentation because we know that people are different, and have different preferences for learning.

You're right that people are opinionated, and that it's difficult to convince them to try new ideas. However, I've been pleasantly surprised at how open the Clojure community has been to our concept and at the momentum it's starting to build.

It'll be interesting to see if other language communities have the same mindset.

It's great you do this really. More ideas on how to actually get to LEGO (promised in software for a long, long time) like development. But yeah, even more than languages, I would think you need a massive following to get traction. Happy the community likes it!

> More ideas on how to actually get to LEGO (promised in software for a long, long time)

I think for this reason the Lego analogy needs to be completely abandoned. Every effort of software modularization has been analogized to Lego at some point, and yet they all fall short. No arhicture claims they are the equivalent of twine glue and toothpicks, even if that's what it ends up being. So any N+1 language/framework/architecture promising it's going to be Lego (for reals this time), even if it does actually deliver, will not be taken seriously when they make the claim.

Well, good ABI/API’s and, let me really clearly separate this from the word ‘good’, standard OS GUI frameworks like Windows wpf and Mac OS X cacao for frontends is as far Lego as I have seen for now. Web frontends is where it all goes terribly wrong; nothing fits and everything breaks when you put X into Y when X and Y are from other authors generally. It is a shit show. But for backends and internally it can be done with good APIs. Problem is… not many people can write those, so you end up with something that says lego on the pack but is in fact lego after your ‘always was a bit weird’ cousin played with it with his flamethrower.

Polylith targets the backend, so I will concentrate my answer around that. I agree that good APIs are important. Polylith helps you with sharing code because it's built around "movable"/decoupled bricks that can be reused across services (e.g. different kinds of APIs). Reuse is a hard problem to solve, and you need LEGO-like building blocks for that.

As a Clojure dude, looking forward to reading. Would appreciate the docs in a single pdf for offline reading. Looks like there are tools that consume a gitbook but would be great if you could just publish a version yourselves!

You can download PDF version of the documentation directly from GitBook. The option is only visible on desktop. When you land on the website, the top most item on the right hand side menu is "Export as PDF".

Not sure if the link will work, but here's the result of clicking "Export PDF" from right sidebar only visible on wider screen.

https://storage.googleapis.com/download/storage/v1/b/gitbook...

I couldn't agree more.

I produce a bit of music and one thing I can never remember how to do without looking it up is side chain compression. I don't use it very often but when I do, I always have to Google what the controls / routing is to be able to do it.

In the beginning it was forum posts, maybe with a couple of images to help illustrate where to click etc. Now it's 10 minute YouTube videos replete with needless introductions about the person creating it and hat in hand begging for likes or subscriptions. You have to go digging to find what you're looking for.

I've been experimenting in this space a bit though (weirdly enough with video game tutorials). I'd be interested in how others find this format for learning or understanding concepts. Here's an example

https://apex-fundamentalists.vodon.gg/videos/0e074984-f9f0-4...

>"It is probably/definitely me but I watched the long video and did not learn anything"

This is because the video says how nice would it be to have a banana without a slightest description of what the banana is and why do we need it. Absolutely useless video. And yes I very much prefer reading a document for understanding concepts.

As for the project itself. I did a very brief reading and I fail to grasp any particular value. Basically what I understood is that if you organize your code in some particular way we will do some particular things.

Maybe if they've presented clear example I would be willing to dig in deeper. For now I've "invested" couple of minutes and watched that "nothing" video and I do not think I'll invest any more time. Maybe it is my loss and their idea is amazing but they definitely do not make it easy to understand what's in it for me.

Before you completely give up on understanding the concept, I would like to suggest you try the 10-minute "Polylith in a Nutshell" video: https://www.youtube.com/watch?v=Xz8slbpGvnk

If you watch it at 1.5x speed, then it'll take less than 7 minutes of your time.

If you're still not getting the "why" of Polylith after this video, then I'd be very grateful if you could give us some quick feedback on what you're missing. That will help us figure out how to explain the concepts better in the future.

That was the video I watched and I just don't get what is different about polylith.

The video spends too long telling me things I already know - e.g. what are functions / objects / layers / etc.

Tell me something I don't know - such as what makes Polylith unique. The video says this is "Components". Well what's so different about those? They sound like microservices or perhaps high-level objects. Or perhaps interfaces.

Show an example!

The idea with that part of the video was to couch the new concept (components) within the framework of existing concepts (functions, objects, layers, etc.) to try to help people connect the new concept at the right place in their knowledge graph. Though your feedback makes me think it didn't work as well as I hoped.

Components do have attributes in common with microservices and with stateless objects (e.g. a public interface and encapsulated implementation).

Where components differ from microservices is that a component's interface is simply a collection of functions, rather than network-facing endpoints. This means that multiple components can be deployed into a single artefact, keeping deployment complexity and cost down.

Where components differ from objects is that a component is a higher-level abstraction, closer in scope to a microservice.

However, we think that Polylith's biggest differentiator is the separation it gives between development and production. Let's say you have a Polylith project with 100 components, that you deploy in production across 10 services. You can work with all 100 components in a single development environment, and test them as though they're a monolith, even though they're not deployed that way in production. It's a lot like building systems with LEGO, and we think its just as fun!

>"Where components differ from microservices is that a component's interface is simply a collection of functions"

Is this a "collection of functions" or "collection of function declarations"? If you want to communicate concepts this is not the best example. And for either case many languages already have the solutions.

Technically, a Polylith interface is a collection of "pass-through" functions, each of which delegate their function call to an "implementation" function within the component.

I agree with you that many languages have syntax to support building interfaces. However, I've yet to come across one that offers all the benefits of Polylith's approach with components.

>"Before you completely give up on understanding the concept, I would like to suggest you try the 10-minute "Polylith in a Nutshell" video"

My lines about the video part was exactly about this particular video.

I was confused because you were replying to a comment which mentioned the "long video", so I assumed you were both talking about the forty-minute one on the homepage of the documentation. My mistake.

Did my response to `cjg` in this thread help to clarify anything for you?

Not really. I suspect that you might have done something that has value in Clojure ecosystem (keep in mind that I do not program in Lisp).

In my ecosystem I simply do not really have problems that you suggest we do and the functionality that you relegate to that "component" idea is not something new and unavailable.

Which ecosystem do you work with? How does it solve the problem of sharing code across service boundaries?

You've answered this question yourself - "Technically, a Polylith interface is a collection of "pass-through" functions, each of which delegate their function call to an "implementation" function within the component."

I work mainly in C++, Delphi/Lazarus, JavaScript. Many others as well but not very often. C++ and Delphi handle the domain just fine. Javascript - bit less convenient still easy.

I'm not sure we're understanding each other. When I asked "How does it solve the problem of sharing code across service boundaries?", I meant how does your language or architecture enable you to share code across separately deployed artefacts, for example across two microservices.

There are three approaches that I'm aware of for solving this problem: 1) copy/paste the shared code between the two repositories, 2) freeze the code into a library that both services depend on, 3) keep both services in one repository, extract the shared code into a module or component, both services depend on the shared module, deploy the services as separate artefacts.

1) is bad for obvious reasons, 2) adds unnecessary friction to the development process, and 3) is how Polylith solves it.

I was wondering if you've come across another way to achieve 3), or perhaps a fourth approach?

I am a vendor. Develop software products from scratch. Sometimes I "hire" myself as I have couple of products that make me money just by me owning and maintaining those.

Pattern goes like this.

1) Client hires me to develop product. After initial phases I determine what parts (code) of other products I can salvage for reuse. At this point I either copy those parts or get the latest version if those parts are 3rd party libraries which at this point is basically the same. So in between different projects I always use approach (1). You are free to laugh at me. I develop for 40 years already and this approach saves me from countless headaches related to "purism". Unless there is really really big reason I do not want to change something in a piece of shared code and then test countless permutations in unrelated projects. Thanks but no thanks. Also once my product reaches maturity I usually transfer it to client.

2) Stage 2 - working on a single product. Even though I avoid "microservices" as deployable like a plague the product still might consist from few physical executables / services. In this case the "components" code is shared as a code and the code uses Interfaces (or simulation in case of Javascript for example) when I feel that I need to abstract some "component" so that I can replace it. so this is your (2) and it poses zero friction to me unlike what you claim.

Types of products I develop ranges from firmware, to game like native applications with device control and accelerated graphic and multimedia, to enterprise backends etc. I have way bigger things to deal with rather than nitpicking whether concept of Component through Interface / library / etc. poses mental / maintenance challenge for me (hint it is not).

Thank you for explaining how you work, and I would never laugh at a developer for copy/pasting code. We've all done it!

I'm still intrigued to understand exactly how you share code across services. Let's say that you've written a piece of code for logging, which you want to use in both service A and service B. Do you package it up in a library? If so, doesn't that mean you have to place that library in a repository, so both services can access it? Doesn't that mean that if you want to make changes to the logging code that you now have to publish a new version of the library, and remember to update both services to depend on the new version?

That's the friction I'm talking about.

With Polylith, the logging code would live in a component that's directly accessible to all the other components in the system. That's because Polylith lets us work with all our components as if they're a monolith (even if we chose to deploy them as multiple services). This means that when we update the logging component, there's zero friction to update any impacted components in the services.

If the change only affects the logging component's implementation (and not its interface) then no other components need to be updated, and we can just redeploy the system. If it's a breaking change to the interface, then we can immediately fix the impacted components within our monolithic development environment. If the change is a refactor of the logging component's interface, then the other components will be automatically updated by our refactoring tool!

Hopefully that explains how Polylith solves this challenge so elegantly.

>"Do you package it up in a library?"

I package it mostly as a code. For example in C++ those would be the header file "xxx.h" ans an interface and "xxx.cpp" as implementation. If I only change the implementation there is no need for me to to touch anything else. Build system will figure out what services (executables) need to be rebuild and relinked. It will then build, deploy, run tests etc while I sit and pick my nose.

Agreed wholeheartedly. It’s something that has been bugging me for a while. I can consume information maybe 3-5x faster (or more?) via text vs video but every trend I can see points to video being the preferred medium for Gen Z.

Is it because they’re “video native” and know how to navigate it better? Surely they’re not sitting through 2 minutes introductions. Do they inherently understand how to return to the important parts of a video for future reference? My brain just does not operate like theirs, it seems.

I wonder the same; often I look up programming things and the first links are videos. So I try to watch one and immediately I think; how can anyone anyone do work like this? I needed a flag for ls and was too lazy to read the man page; the result was already put in 1 line on top by Google. Of course I needed only 5 chars only. Then I clicked the video that answered the question for fun; I will try to find it but I think it was 15 minutes of drivel… I just don’t get it. I mean sure I understand why the video makers do it, but who consumes this crap? And why? And it is getting worse; I like watching live streams of programming, but when you actually want to learn something and therefor need to enter code yourself, there is nothing more inefficient medium than video imho.

It could be habit from the wiring of their brain being setup for video from social media.

But following your idea of finding a reason that assumes it's actually more beneficial learning from video than text for people in that class, you need to consider two alternatives.

The first is that they are better at video, but the second is that they are worse as long form text.

Oh yea, I totally assume that they know what they’re doing. It’s just clear that I’m not wired that way. I didn’t grow up with videos accessible to the point of ubiquity like Z has.

I guess my point is that it's possibly/probably an objectively worse way of ingesting information. It's always going to be faster to skim text to find what you need that watching a video on high speed.

But is it? That seems “obvious” to us “old” millennials+. But is an entire generation all independently wrong, and doing the slow thing? If so, why? Is there evidence supporting this that we can look at? All genuine questions, I don’t know the answers. But there’s something interesting happening there, that I do know.

Video is nice for multitasking. I can't read and do anything else at the same time. I can listen to a video, glance at it, and do other things too.

There’s absolutely no way you’re internalizing what’s in that video while it’s playing in the background.

That's my issue too; it is fine for tv shows and movies to register if they are worth watching 'for real', but also there, if I am working on something hard, I often notice that 4 episodes have passed and I have 0 clue what happened.

Sure there is. I code while watching videos all the time.

Reply on news.ycombinator.com