3 ms·

Now we just need to wait a couple more decades till functional Java is adopted. So far I'm still seeing complex class hierarchies with deep inheritance, depend

by hbrn 4y ago

Now we just need to wait a couple more decades till functional Java is adopted. So far I'm still seeing complex class hierarchies with deep inheritance, dependency injection and unit tests produced by ex-Java developers for something that can be solved with a couple of simple methods in Python. I noticed that complexity makes Java folks proud. Conversely, simplicity makes Python folks proud. Seeing Java on a resume is not yet a reason not to hire for me. But it's a signal that indicates greater risks.

PaulHoule 4y ago
So you think unit tests are a bad idea?
- hbrn 4y ago
  As a matter of fact I do think unit tests generally cause more harm than good. They are great for libraries with well defined and slowly evolving interfaces. But unless you're doing open-source, you will rarely work on those. Write tests. Not too many. Mostly integration. https://kentcdodds.com/blog/write-tests https://kentcdodds.com/blog/write-tests
  - quantified 4y ago
    Any internal library used by multiple other teams has friction on its evolution and refactoring, and don't change interfaces all that much. Perhaps this turns into another round of clarifying what the discussion participants deem "unit" vs "integration".
    - hbrn 4y ago
      Every company is different, but my preference is to break into teams by domain/network boundary. In this case sharing libraries is extremely rare. Teams could easily be on different tech stacks. Edit: my experience is mostly between seed - series B startups. If you're Google, then of course you're going to have a ton of internal libraries. But I'd put it in the same category as open source.
    - PaulHoule 4y ago
      One role of tests is documentation. If you have a large number of examples of how to use an API you know they keep working. Any code snippet used for documentation should have a corresponding test because otherwise the docs will probably break someday. It’s the best case for ‘literate programming’ that there is.
icedchai 4y ago
Odd. I typically see more unit tests on Python projects due to the lack of static typing. I'd take a large Java project over a large Python project any day.
Zardoz84 4y ago
Funny... I have a discussion with a teammate, where he thinks that our internal API should not return streams. I stead we must return Lists, Sets or Maps
- PaulHoule 4y ago
  I think lambdas and everything around them except the streams API is pretty good, but the streams API is pants. It adds a lot of overhead but doesn’t take advantage of the global view of the processing pipeline it has. I wrote my own competitor at http://gihub.com/paulhoule/pidove/ http://gihub.com/paulhoule/pidove/ which looks lispy because it uses static imports for everything. I started on a fluent syntax version but wound up working on another project. The odd thing is that I wound up studying the streams API in enough detail that I got over many of the complaints I had about it. If I was going to put more work into pidove it would be developing it to make the most of the Collections API so if you, say, map a list, it returns a list that lets you get(7) to only map that item.

by hbrn 4y ago

PaulHoule 4y ago

So you think unit tests are a bad idea?

hbrn 4y ago
As a matter of fact I do think unit tests generally cause more harm than good. They are great for libraries with well defined and slowly evolving interfaces. But unless you're doing open-source, you will rarely work on those. Write tests. Not too many. Mostly integration. https://kentcdodds.com/blog/write-tests https://kentcdodds.com/blog/write-tests
- quantified 4y ago
  Any internal library used by multiple other teams has friction on its evolution and refactoring, and don't change interfaces all that much. Perhaps this turns into another round of clarifying what the discussion participants deem "unit" vs "integration".
  - hbrn 4y ago
    Every company is different, but my preference is to break into teams by domain/network boundary. In this case sharing libraries is extremely rare. Teams could easily be on different tech stacks. Edit: my experience is mostly between seed - series B startups. If you're Google, then of course you're going to have a ton of internal libraries. But I'd put it in the same category as open source.
  - PaulHoule 4y ago
    One role of tests is documentation. If you have a large number of examples of how to use an API you know they keep working. Any code snippet used for documentation should have a corresponding test because otherwise the docs will probably break someday. It’s the best case for ‘literate programming’ that there is.

icedchai 4y ago

Odd. I typically see more unit tests on Python projects due to the lack of static typing. I'd take a large Java project over a large Python project any day.

Zardoz84 4y ago

Funny... I have a discussion with a teammate, where he thinks that our internal API should not return streams. I stead we must return Lists, Sets or Maps

PaulHoule 4y ago
I think lambdas and everything around them except the streams API is pretty good, but the streams API is pants. It adds a lot of overhead but doesn’t take advantage of the global view of the processing pipeline it has. I wrote my own competitor at http://gihub.com/paulhoule/pidove/ http://gihub.com/paulhoule/pidove/ which looks lispy because it uses static imports for everything. I started on a fluent syntax version but wound up working on another project. The odd thing is that I wound up studying the streams API in enough detail that I got over many of the complaints I had about it. If I was going to put more work into pidove it would be developing it to make the most of the Collections API so if you, say, map a list, it returns a list that lets you get(7) to only map that item.