6 ms·

I put coloured glasses on the past because back then companies didn't request developers to know more than one programming language. They just used fancy words

I put coloured glasses on the past because back then companies didn't request developers to know more than one programming language. They just used fancy words for simple tasks.

thanks_dang 2y ago
Developers were more in tune with the entire tech stack down to silicone. Today you’d be “unreasonable” for asking such a thing.
- atomicnumber3 2y ago
  Yeah because back then the tech stack was: php apache mysql linux it was so small we could put it into an acronym. Meanwhile in 2024 you could barely begin to even describe any individual layer of the stack with so few words. You'd be out of breath before even beginning to finish describing React. (btw it's silicon, not silicone).
  - athorax 2y ago
    Good ole PAML stack :)
- rmanolis 2y ago
  I am not asking, it will be the only way from now on if companies don't want to waste more money and time. Because the option to parse stack traces from the programming language itself, it will destroy what ever built on or for microservices
- DHRicoF 2y ago
  The entire stack down to silicon exploded multiplied by 3 or 4 in that time. Vectorization, more cache levels, branch prediction, multiple cores and processors, gpu, virtual machines, (operating systems, but they didn't change much, I only let the placeholder for the layer), containers, but all that in the cloud, distributed databases, frameworks written in a language that need to be compiled to a language that is actually implemented by a web browser in the client (we are far better on compatibility between browsers, but much libraries or practices keep stuck in the past). I haven't touched shift in practices that make it far worse. That make it more unreasonable.
teaearlgraycold 2y ago
What problem do you have with companies requesting developers know more than one language? If they want a master in multiple then they are fools. But a web developer for example will need proficiency in a few.
- rmanolis 2y ago
  First, in the article I wrote how detrimental it is to the developer's social life, to know multiple languages. Secondly, companies need to realize that they request multiple programming languages because the current programming languages can't parse stack traces, and they push everything to microservices, so they can parse their errors from DevOps services. Which means they don't request only to know multiple languages, but also DevOps services. I have written about all these in a previous article of mine https://rm4n0s.github.io/posts/5-it-will-take-your-job https://rm4n0s.github.io/posts/5-it-will-take-your-job
  - tharkun__ 2y ago
    in the article I wrote how detrimental it is to the developer's social life, to know multiple languages. That is an opinion and not fact. One based on your personal experience that is not universal in any way. Knowing multiple programming languages is quite normal and I would expect any good software developer to pick and up be able to program in (almost) any language. I guess https://en.wikipedia.org/wiki/Brainfuck https://en.wikipedia.org/wiki/Brainfuck might be an exception. JCL comes close to it. We learned this in high school and it was super fun: https://en.wikipedia.org/wiki/Busy_beaver https://en.wikipedia.org/wiki/Busy_beaver Do I expect everyone to be an instant expert in any language? Or able to create the busiest beaver? No of course not! But I do expect any decent programmer to pick up any programming language and work in it. Do we all have preferences? Heck yes! I absolutely dislike Python and would not take a job where I have to program in it if I wasn't forced to by circumstances. I've never done C# or Lua professionally but it was super easy to pick both up when I dabbled with them for game development in private (each respective game engine used these languages for scripting). Secondly, companies need to realize that they request multiple programming languages because the current programming languages can't parse stack traces I read something like that in the article and it still makes no sense whatsoever when I read it here either. Parsing a stack trace in various languages is absolutely possible. But what's that got to do with anything? FWIW, yes, I've actually looked at previous stack frames (e.g. `e.getCause()` in Java) for error handling. It always felt very very dirty but it was my only choice under the circumstances. they push everything to microservices We have to distinguish the why there. Some companies (meaning the people within those companies) because they read about how Netflix has x-many of them and it's the thing to do today. Stay away from those companies. They will also make you do other things just because someone read an article of forbes.com. And then there's companies that are actually trying to solve similar problems as the ones that Netflix was trying to solve with microservices and it actually makes sense to model their internal application service landscape that way! We're in that space for example. We have one big legacy "macroservice" aka very monolithic core and then we have a bunch of newer microservices (some larger, some smaller) that actually solve problems. All of these microservices are written in exactly two languages: Java and Kotlin. Newer ones in Kotlin, older ones in Java (like the legacy monolith). The FE is written in exactly one language by now: Typescript (converted from quite a large javascript code base over multiple years). so they can parse their errors from DevOps services What does that even mean? Makes no sense to me whatsoever. If you're talking about having a central log analytics service like Splunk, Datadog or Graylog et al. then that has nothing to do with microservices or multiple languages. At a previous place we had a bunch of monoliths make up the overall application and splunk so that you'd be able to actually reason about what the system overall was doing for any given overall user transaction / session and it was awesome to have. And if you have any sort of actual need to run software that has uptime requirements, then you are going to run at least two replicas of whatever service you created, monolith or not and you want a central log aggregation service. I'm really sorry to say this, but it seems like your articles are really just ranting about things that you personally don't like for one reason or another but there's no actual real reasoning or universal truth to it.
tharkun__ 2y ago
Yes they did. My dad worked in IBM 360 assembler. And in COBOL. And in Natural (yes that's actually a programming language - https://documentation.softwareag.com/natural/nat426mf/pg/pg-over.htm https://documentation.softwareag.com/natural/nat426mf/pg/pg-...) And JCL. And I am probably forgetting some. And they had learn their "Hibernate" and JPA etc too (CICS comes to mind). Also in a similar regard your article mentions other things like microservices being the root of all evil so to speak and you need to know multiple services. When in fact microservices are meant to do the opposite. You are supposed to be able to focus on just your service and what it needs to do and make it do it well. Instead of having to wade through a huge monolithic and probably very interwoven code base. We can of course talk about whether microservices achieved that goal. They are not fundamentally different from having worked in large enterprises 25 years ago where you would've encountered many many different services making up your application landscape. It was probably using SOA and the services were deployed to a bunch of application servers like an IBM WebSphere and those services might be talking to other services incidentally deployed on some JBoss app servers and they'd talk via message passing via a queue (JMS comes to mind but other ways existed).
- rmanolis 2y ago
  Did your Dad worked on IBM 360 assembler, COBOL, Natural and JCL on the same day? today fullstack developers have to pivot between 2-3 languages on the same day All the SOA back then was JAVA, they had just different types of HTTP servers to run JAVA
  - tharkun__ 2y ago
    All four probably not. He might have worked on some feature in COBOL that then required a new/change to a channel program that would have been written in assembler and at the end of the day write some JCL to get a job to start. Yes. I constantly write software in Typescript, Java and Kotlin. Some days it's all of them other days it's only a subset. I don't see an issue with that at all. If you don't have a standard set of languages I would agree with you but a stack of one frontend and one backend language should not be a problem for anyone that calls themselves full stack. The SOA point was not about languages any longer. It was about having multiple services that make up an overall feature and app landscape. Also you seem to have missed the part where I said that I was not in fact HTTP calls is manyif not most cases ;)

I put coloured glasses on the past because back then companies didn't request developers to know more than one programming language. They just used fancy words for simple tasks.

thanks_dang 2y ago

Developers were more in tune with the entire tech stack down to silicone. Today you’d be “unreasonable” for asking such a thing.

atomicnumber3 2y ago
Yeah because back then the tech stack was: php apache mysql linux it was so small we could put it into an acronym. Meanwhile in 2024 you could barely begin to even describe any individual layer of the stack with so few words. You'd be out of breath before even beginning to finish describing React. (btw it's silicon, not silicone).
- athorax 2y ago
  Good ole PAML stack :)
rmanolis 2y ago
I am not asking, it will be the only way from now on if companies don't want to waste more money and time. Because the option to parse stack traces from the programming language itself, it will destroy what ever built on or for microservices
DHRicoF 2y ago
The entire stack down to silicon exploded multiplied by 3 or 4 in that time. Vectorization, more cache levels, branch prediction, multiple cores and processors, gpu, virtual machines, (operating systems, but they didn't change much, I only let the placeholder for the layer), containers, but all that in the cloud, distributed databases, frameworks written in a language that need to be compiled to a language that is actually implemented by a web browser in the client (we are far better on compatibility between browsers, but much libraries or practices keep stuck in the past). I haven't touched shift in practices that make it far worse. That make it more unreasonable.

teaearlgraycold 2y ago

What problem do you have with companies requesting developers know more than one language? If they want a master in multiple then they are fools. But a web developer for example will need proficiency in a few.

rmanolis 2y ago
First, in the article I wrote how detrimental it is to the developer's social life, to know multiple languages. Secondly, companies need to realize that they request multiple programming languages because the current programming languages can't parse stack traces, and they push everything to microservices, so they can parse their errors from DevOps services. Which means they don't request only to know multiple languages, but also DevOps services. I have written about all these in a previous article of mine https://rm4n0s.github.io/posts/5-it-will-take-your-job https://rm4n0s.github.io/posts/5-it-will-take-your-job
- tharkun__ 2y ago
  in the article I wrote how detrimental it is to the developer's social life, to know multiple languages. That is an opinion and not fact. One based on your personal experience that is not universal in any way. Knowing multiple programming languages is quite normal and I would expect any good software developer to pick and up be able to program in (almost) any language. I guess https://en.wikipedia.org/wiki/Brainfuck https://en.wikipedia.org/wiki/Brainfuck might be an exception. JCL comes close to it. We learned this in high school and it was super fun: https://en.wikipedia.org/wiki/Busy_beaver https://en.wikipedia.org/wiki/Busy_beaver Do I expect everyone to be an instant expert in any language? Or able to create the busiest beaver? No of course not! But I do expect any decent programmer to pick up any programming language and work in it. Do we all have preferences? Heck yes! I absolutely dislike Python and would not take a job where I have to program in it if I wasn't forced to by circumstances. I've never done C# or Lua professionally but it was super easy to pick both up when I dabbled with them for game development in private (each respective game engine used these languages for scripting). Secondly, companies need to realize that they request multiple programming languages because the current programming languages can't parse stack traces I read something like that in the article and it still makes no sense whatsoever when I read it here either. Parsing a stack trace in various languages is absolutely possible. But what's that got to do with anything? FWIW, yes, I've actually looked at previous stack frames (e.g. `e.getCause()` in Java) for error handling. It always felt very very dirty but it was my only choice under the circumstances. they push everything to microservices We have to distinguish the why there. Some companies (meaning the people within those companies) because they read about how Netflix has x-many of them and it's the thing to do today. Stay away from those companies. They will also make you do other things just because someone read an article of forbes.com. And then there's companies that are actually trying to solve similar problems as the ones that Netflix was trying to solve with microservices and it actually makes sense to model their internal application service landscape that way! We're in that space for example. We have one big legacy "macroservice" aka very monolithic core and then we have a bunch of newer microservices (some larger, some smaller) that actually solve problems. All of these microservices are written in exactly two languages: Java and Kotlin. Newer ones in Kotlin, older ones in Java (like the legacy monolith). The FE is written in exactly one language by now: Typescript (converted from quite a large javascript code base over multiple years). so they can parse their errors from DevOps services What does that even mean? Makes no sense to me whatsoever. If you're talking about having a central log analytics service like Splunk, Datadog or Graylog et al. then that has nothing to do with microservices or multiple languages. At a previous place we had a bunch of monoliths make up the overall application and splunk so that you'd be able to actually reason about what the system overall was doing for any given overall user transaction / session and it was awesome to have. And if you have any sort of actual need to run software that has uptime requirements, then you are going to run at least two replicas of whatever service you created, monolith or not and you want a central log aggregation service. I'm really sorry to say this, but it seems like your articles are really just ranting about things that you personally don't like for one reason or another but there's no actual real reasoning or universal truth to it.

tharkun__ 2y ago

Yes they did. My dad worked in IBM 360 assembler. And in COBOL. And in Natural (yes that's actually a programming language - https://documentation.softwareag.com/natural/nat426mf/pg/pg-over.htm https://documentation.softwareag.com/natural/nat426mf/pg/pg-...) And JCL. And I am probably forgetting some. And they had learn their "Hibernate" and JPA etc too (CICS comes to mind). Also in a similar regard your article mentions other things like microservices being the root of all evil so to speak and you need to know multiple services. When in fact microservices are meant to do the opposite. You are supposed to be able to focus on just your service and what it needs to do and make it do it well. Instead of having to wade through a huge monolithic and probably very interwoven code base. We can of course talk about whether microservices achieved that goal. They are not fundamentally different from having worked in large enterprises 25 years ago where you would've encountered many many different services making up your application landscape. It was probably using SOA and the services were deployed to a bunch of application servers like an IBM WebSphere and those services might be talking to other services incidentally deployed on some JBoss app servers and they'd talk via message passing via a queue (JMS comes to mind but other ways existed).

rmanolis 2y ago
Did your Dad worked on IBM 360 assembler, COBOL, Natural and JCL on the same day? today fullstack developers have to pivot between 2-3 languages on the same day All the SOA back then was JAVA, they had just different types of HTTP servers to run JAVA
- tharkun__ 2y ago
  All four probably not. He might have worked on some feature in COBOL that then required a new/change to a channel program that would have been written in assembler and at the end of the day write some JCL to get a job to start. Yes. I constantly write software in Typescript, Java and Kotlin. Some days it's all of them other days it's only a subset. I don't see an issue with that at all. If you don't have a standard set of languages I would agree with you but a stack of one frontend and one backend language should not be a problem for anyone that calls themselves full stack. The SOA point was not about languages any longer. It was about having multiple services that make up an overall feature and app landscape. Also you seem to have missed the part where I said that I was not in fact HTTP calls is manyif not most cases ;)