5 ms·

Isn't this just Object Oriented API Design 101? I kept reading, looking for the punch line, but as far as I can tell he's just describing really basic informat

Isn't this just Object Oriented API Design 101? I kept reading, looking for the punch line, but as far as I can tell he's just describing really basic information hiding and interface design. Maybe it's OOD For Server Programmers? There's nothing wrong with it, it's just surprising to me that it's news.

yummyfajitas 12y ago
The only punch line is "hey microservice hipsters, those uncool Enterprise Java guys already solved this problem."
- valarauca1 12y ago
  Hasn't that been the punch line of the last 10 years of tech? "Oh hey data hipsters, no I'm sorry our SQL data base is 200TB, no we don't have performance problems." "Oh no we don't need your functional restless framework, we've been using a java framework for like 10 years, it peaks out at 1000 req/s." "Why would we buy 4 webservers? It has 4 nics, and 8 CPU sockets. Sure it costs 500k each, but then we can keep using our java framework."
  - danielweber 12y ago
    I find it useful to read articles by someone who will translate from hipster to crotchety-unix-grey-beard for me.
    - valarauca1 12y ago
      c2wiki does that for you ^-^
  - omouse 12y ago
    Yep, in the last few years I keep thinking, "Maybe it's time to get over my distaste for Java and just use it". They have some kind of type system, lots of pretty good tools (aside from Eclipse) and documentation for even the crappiest Java library is light years ahead of what you get with most JavaScript projects (even API docs for Java libs are easier to navigate and read!)
- buckbova 12y ago
  We talking java beans. I think I used that first (and last) 15 years ago and it was ugly to work with.
  - abollaert 12y ago
    Technically it's EJB (Enterprise Java Beans), JavaBeans is a pattern where you need to adhere to particular coding conventions (getters, setters, naming of said getters and setters). I also used to work with these a long time ago (EJB 1.1 and 2.0). A lot has changed since then though, and EJB 3 has solved a lot of the pain points (arguably pushed by the success of concepts used in Spring and Hibernate, whose authors served in the JCP for the newer JEE specs).
- LunaSea 12y ago
  Completely forgetting that application architecture and design is constrained by time and that those "uncool Entreprise Java guys" actually have much more time to work on "heavy" architectures compared to web services.
  - yummyfajitas 12y ago
    How do Service Objects require more time than microservices? If anything I've found they take less time - logically the code is similar to microservices and you need to spend less time on devops.
    - lmm 12y ago
      You're forced to explicitly define the interface. While I think the advantages of an explicit interface are well worth it, I can write a Javascript microservice with no defined interface faster than I can write an interface declaration + implementation in Scala.
- SomeCallMeTim 12y ago
  I guess. Though those Enterprise Java guys were using concepts developed in the '50s and '60s, well before Java existed. [1] [1] https://en.wikipedia.org/wiki/Object-oriented_programming#History https://en.wikipedia.org/wiki/Object-oriented_programming#Hi...
  - fleitz 12y ago
    Every Java program becomes a bug ridden slow version of half of Common Lisp (implemented in xml)
tdicola 12y ago
My thoughts too--I couldn't understand why so many words had to be written to describe an interface and a concrete implementation.
ebiester 12y ago
Do you remember when you were a junior programmer? Did you ever have a crotchety senior programmer, after being shown a webapp's source code, say "this is terrible. It's fine for web pages, but this coding style is shit." Slowly and surely, we relearned all of the lessons the mainframe designers had learned, and it became heavyweight. The new generation is working on smaller problems and saying, "This is heavyweight!" And then they go with a minimalist solution, and the problem space grows. They then learn the lessons the crotchety senior programmers had told them. Microservices is but one more example. Decrease coupling, increase cohesion. And then they'll get into hairier and hairier problems and rediscover the problems the last time someone tried it. Remember when service oriented architecture was the buzzword? :) To be fair, each generation iterates on the past. I'd rather code today than the 80s. However, each generation, each programmer has to learn the lessons again. Usually, we learn the hard way.
- SomeCallMeTim 12y ago
  When I was a "junior programmer" at 14 or so, I thought BASIC was too slow so I learned assembly language and wrote a game in it. And then several more, some professionally. When I first encountered OOD, I lapped it up and became an acolyte. Then I discovered how OOD didn't actually solve ALL problems well. Now I consider myself post-OOD; I use the parts that are useful when they're useful, and otherwise I use other paradigms. I became a fan of and later gave up on Ruby as a language before Rails existed. I don't think I've ever been the junior programmer you just described.
ttctciyf 12y ago
I had this, too, but then when I got to it, I thought the punchline was when the service object was revealed as potentially just a wrapper for a call to a microservice under its hood, and the ensuing warning about 'network partition' (this is modernese for 'network breakage', right? Right.)
abollaert 12y ago
In the case of EJB and so on, it's not just OO concepts. You also have declarative distributed transactions and nesting of these transactions, role based security with a shared context. I thought the concepts were originally based on CORBA, which is even older.

yummyfajitas 12y ago

The only punch line is "hey microservice hipsters, those uncool Enterprise Java guys already solved this problem."

valarauca1 12y ago
Hasn't that been the punch line of the last 10 years of tech? "Oh hey data hipsters, no I'm sorry our SQL data base is 200TB, no we don't have performance problems." "Oh no we don't need your functional restless framework, we've been using a java framework for like 10 years, it peaks out at 1000 req/s." "Why would we buy 4 webservers? It has 4 nics, and 8 CPU sockets. Sure it costs 500k each, but then we can keep using our java framework."
- danielweber 12y ago
  I find it useful to read articles by someone who will translate from hipster to crotchety-unix-grey-beard for me.
  - valarauca1 12y ago
    c2wiki does that for you ^-^
- omouse 12y ago
  Yep, in the last few years I keep thinking, "Maybe it's time to get over my distaste for Java and just use it". They have some kind of type system, lots of pretty good tools (aside from Eclipse) and documentation for even the crappiest Java library is light years ahead of what you get with most JavaScript projects (even API docs for Java libs are easier to navigate and read!)
buckbova 12y ago
We talking java beans. I think I used that first (and last) 15 years ago and it was ugly to work with.
- abollaert 12y ago
  Technically it's EJB (Enterprise Java Beans), JavaBeans is a pattern where you need to adhere to particular coding conventions (getters, setters, naming of said getters and setters). I also used to work with these a long time ago (EJB 1.1 and 2.0). A lot has changed since then though, and EJB 3 has solved a lot of the pain points (arguably pushed by the success of concepts used in Spring and Hibernate, whose authors served in the JCP for the newer JEE specs).
LunaSea 12y ago
Completely forgetting that application architecture and design is constrained by time and that those "uncool Entreprise Java guys" actually have much more time to work on "heavy" architectures compared to web services.
- yummyfajitas 12y ago
  How do Service Objects require more time than microservices? If anything I've found they take less time - logically the code is similar to microservices and you need to spend less time on devops.
  - lmm 12y ago
    You're forced to explicitly define the interface. While I think the advantages of an explicit interface are well worth it, I can write a Javascript microservice with no defined interface faster than I can write an interface declaration + implementation in Scala.
SomeCallMeTim 12y ago
I guess. Though those Enterprise Java guys were using concepts developed in the '50s and '60s, well before Java existed. [1] [1] https://en.wikipedia.org/wiki/Object-oriented_programming#History https://en.wikipedia.org/wiki/Object-oriented_programming#Hi...
- fleitz 12y ago
  Every Java program becomes a bug ridden slow version of half of Common Lisp (implemented in xml)

tdicola 12y ago

My thoughts too--I couldn't understand why so many words had to be written to describe an interface and a concrete implementation.

ebiester 12y ago

Do you remember when you were a junior programmer? Did you ever have a crotchety senior programmer, after being shown a webapp's source code, say "this is terrible. It's fine for web pages, but this coding style is shit." Slowly and surely, we relearned all of the lessons the mainframe designers had learned, and it became heavyweight. The new generation is working on smaller problems and saying, "This is heavyweight!" And then they go with a minimalist solution, and the problem space grows. They then learn the lessons the crotchety senior programmers had told them. Microservices is but one more example. Decrease coupling, increase cohesion. And then they'll get into hairier and hairier problems and rediscover the problems the last time someone tried it. Remember when service oriented architecture was the buzzword? :) To be fair, each generation iterates on the past. I'd rather code today than the 80s. However, each generation, each programmer has to learn the lessons again. Usually, we learn the hard way.

SomeCallMeTim 12y ago
When I was a "junior programmer" at 14 or so, I thought BASIC was too slow so I learned assembly language and wrote a game in it. And then several more, some professionally. When I first encountered OOD, I lapped it up and became an acolyte. Then I discovered how OOD didn't actually solve ALL problems well. Now I consider myself post-OOD; I use the parts that are useful when they're useful, and otherwise I use other paradigms. I became a fan of and later gave up on Ruby as a language before Rails existed. I don't think I've ever been the junior programmer you just described.

ttctciyf 12y ago

I had this, too, but then when I got to it, I thought the punchline was when the service object was revealed as potentially just a wrapper for a call to a microservice under its hood, and the ensuing warning about 'network partition' (this is modernese for 'network breakage', right? Right.)

abollaert 12y ago

In the case of EJB and so on, it's not just OO concepts. You also have declarative distributed transactions and nesting of these transactions, role based security with a shared context. I thought the concepts were originally based on CORBA, which is even older.