re: The broken promise of static typing VIEW POST

re: Hi Dan, Thanks for taking the time to reply. My comments below. I prefer a simple language with simple features :). You claim: "the number of b...

Hi Madusudanan,

I see that when we talk about simplicity, we are not using it in the same way. In the article I mean "simple" as per Rich Hickey definition, which he explains in this one hour presentation.

Funny that you need one hour to explain what simple means :).

About large projects, I haven't personally work in any large codebase for the last ten years of my career as I have been doing SOA/Microservices.

What do you think about microservices? Isn't it a way of avoiding big complex codebases?

We are leaning towards the same definition of simple. But where we differ is how it is implemented in languages. You should take a look at martin odersky's talk working hard to keep it simple. A language being complex to learn is not necessarily the same as its usage in applications. There are some languages that get this right, such as scala.

What do you think about microservices? Isn't it a way of avoiding big complex codebases?

I don't think microservices is the only answer. Services can be split if they naturally have a boundary. In my experience if the application talks to the same database schema then it would be unnecessary overhead to create everything as a micro service i.e instead of database calls we would now be using REST APIs. HTTP while being a good protocol is definitely not a replacement for regular method calls within a language. I tell this because most of the microservices discussion end in a way that split everything as small as possible, which is definitely not the goal of microservices.

But it can definitely help to a great extend if done right.

Of course my experience is limited and I am not an expert in any way. Just my 2 cents.

code of conduct - report abuse