4 ms·

Yeah, keep writing perl and spout cynicism about everything. I feel like they are chasing a aesthetic of conciseness, their perfect little haskell program, not

Yeah, keep writing perl and spout cynicism about everything. I feel like they are chasing a aesthetic of conciseness, their perfect little haskell program, not recognizing that regularity and good api design are much more important. What is beautiful for a 100loc program becomes ugly and wrong for a 100kloc program. Other aspects become much more important. I'm not a huge fan of go, but it proved there is a necessity for boringness in cooperation. Boring syntax does not mean the upper limit is mediocrity, saying that is revealing shallowness.

zozbot234 5y ago
The notion that languages focused on writing large-scale programs must be "boring" seems a bit silly. What these languages need is lots of ways to define sensible modularity boundaries, and the "boring" aesthetic (or lack thereof, rather) can really get in the way of that.
- pjmlp 5y ago
  The point being that at scale all code should be written the same way, in an environment where most teams are composed of rotating consultants.
  - marcosdumay 5y ago
    Well, the counterpoint is that you shouldn't have a team composed of rotating consultants. And if you have one, you can't expect it to deliver anything with any quality or productivity. But yes, if that's your team, then all code should be written the same way, all on the most boring way possible. There's a reason Java and C# are so popular.
    - pjmlp 5y ago
      This is the modus operanti from all Fortune 500 whose main business isn't shipping software, for them IT is a cost center.
      - marcosdumay 5y ago
        As I said, there's a reason Java and C# are so popular. And it may not even be a bad thing, I don't know the overall impact. It does cut a lot of good developers that could be creating great software out of it, but it also opens space for a lot of people that wouldn't add value in a different environment. It also adds a great deal of costs due to the bad software, but it probably increases the amount of problems we can solve with software.
    - zozbot234 5y ago
      > But yes, if that's your team, then all code should be written the same way, all on the most boring way possible. I agree that code should be written to be "as boring as possible" but even then, it's not clear that a "boring" language helps. What you really want in your scenario is very extensive and up-to-date documentation, both of inter-module boundaries and within individual modules. Java and C# supposedly try to make this easy, but mostly fail. The real reason they're still so popular is that they're easy to "learn" up to some not-even-barely-tolerable standard for the average cheap consultant.
    - ysleepy 5y ago
      This is short sighted. Teams do not build everything from scratch, probably most shipped executables are 90% outside libraries, open source or not. Code being predictable is a huge win, not only with other people but also with your own code from 10months ago. It also makes change more calculable.
- Consultant32452 5y ago
  I would submit that any language that reaches the level of adoption that Java does will be considered boring. The human mind has a tendency to prefer new/fresh things, particularly for people high in trait openness (big 5 personality traits).
  - ReleaseCandidat 5y ago
    > I would submit that any language that reaches the level of adoption that Java does will be considered boring. I know of nobody who would call Javascript or C++ boring ;). Or compare COBOL (boring) with Fortran if you prefer something from the past.
    - Consultant32452 5y ago
      I don't know anyone who is excited about learning C++. The excitement around JS is trying to make it not be like JS.
- gmueckl 5y ago
  TL/DR: it's about readability and clarity of unfamiliar code. One problem of large codebases is that they tend to be team efforts. Given a a sufficiently large and flexible language, each team member will find their own style and idioms for their code. This creates the subtle problem that team members are unfamiliar with each other's styles and when they touch the same pieces of code, they each extend the subset of used language features by whatever is required for their favorite idioms. Eventually, the resulting code gets too elaborate for its own good and maintainability goes down. A boring, simplified language ideally constrains the team to use more or less the same patterns and idioms and this side-steps the problem.
- lenkite 5y ago
  Boring Is Best! When you have junior programmers joining/leaving teams, consistent, boring code written in one Boring PL according to Boring Code Conventions is like driving on a freeway in one straight direction with auto-pilot on. Clever code written in half-a-dozen Cool PL's is like driving for your life in sharply turning mountain roads with no guard-rails - something guaranteed to become cataclysmic as your number of issues/escalations rise and rise, your tech debt becomes an un-surmountable mountain and you watch your hair turn grey before you are middle-aged.
- jimbokun 5y ago
  > What these languages need is lots of ways to define sensible modularity boundarie One of the most important modularity boundaries is dependencies on libraries written by others. So a good, easy to use dependency manager and a straight forward mechanism for creating and sharing libraries is crucial. Java does really well in this regard.
the_af 5y ago
> regularity and good api design are much more important Do note these are more than a little flaky with many of the Java libs out there ;) There's a bit of everything, good quality and poor Java code. It's just that there is so much of it out there, that a lot tends to be crud.
- throwaway2037 5y ago
  Can I say one thing that is great about the JAR ecosystem -- at least in a safe "closed moat" enterprise setting? Monkey patching buggy JARs! In my experience (and many others!), it is pretty common to manage an enterprise Java project that is stuck on an ancient version of a JAR. (This can be true in any language.) If you find a bug, it might be too hard to upgrade to the latest version. But you can easily copy the source code into your project and monkey patch it. Yeah, it won't win any awards, but it keep the ball of mud rolling forward. Yes, I know this technique can be used in lots of other languages. Also, you make it sound like Java -- in particular -- has a lot of poor open source libraries. I would say the same for Perl. I wrote it for many years, and I was constantly working around tiny bugs in open source libraries. This isn't a comment on Perl or people who contribute to open source Perl libraries. Rather, this is the reality of using a huge amount open source libraries. About 98 to 99% will be "good enough". Then, you need to hack around the last 1-2% buggy bits. One thing I have noticed in general (JavaScript, Python, DotNet, Java, C++), in the last 10 years, there has been a dramatic rise in unit tests in open source libraries. Fifteen years ago, you were lucky to have any unit tests. Some of the best libraries now advertise their unit test code coverage on GitHub. It is great progress.
  - the_af 5y ago
    I actually agree with all of what you say. I have done monkeypatching of that sort -- as a workaround for some bug in Apache Wicket, I forget the details -- and it wasn't elegant but it worked. Also agreed, I'm sure other ecosystems share these problems. I know nothing of Perl, but I trust you on that.
  - chefandy 5y ago
    I’ve never used the jar monkey patching workflow (or gone much further with Java than some getting started guides in the 90s,) so I could be wrong, but it seems akin to opening up a new high-interest line of credit to pay down your current debt. Everyone has a plan to pay it down before the promo APR expires, but most end up making the minimum monthly payments and a year later have yesterdays debt with higher, retroactively-applied interest. Unless you know of an imminent replacement or resource boost, assuming there will be a better time to actually solve the root problem seems crazy.

zozbot234 5y ago

The notion that languages focused on writing large-scale programs must be "boring" seems a bit silly. What these languages need is lots of ways to define sensible modularity boundaries, and the "boring" aesthetic (or lack thereof, rather) can really get in the way of that.

pjmlp 5y ago
The point being that at scale all code should be written the same way, in an environment where most teams are composed of rotating consultants.
- marcosdumay 5y ago
  Well, the counterpoint is that you shouldn't have a team composed of rotating consultants. And if you have one, you can't expect it to deliver anything with any quality or productivity. But yes, if that's your team, then all code should be written the same way, all on the most boring way possible. There's a reason Java and C# are so popular.
  - pjmlp 5y ago
    This is the modus operanti from all Fortune 500 whose main business isn't shipping software, for them IT is a cost center.
    - marcosdumay 5y ago
      As I said, there's a reason Java and C# are so popular. And it may not even be a bad thing, I don't know the overall impact. It does cut a lot of good developers that could be creating great software out of it, but it also opens space for a lot of people that wouldn't add value in a different environment. It also adds a great deal of costs due to the bad software, but it probably increases the amount of problems we can solve with software.
  - zozbot234 5y ago
    > But yes, if that's your team, then all code should be written the same way, all on the most boring way possible. I agree that code should be written to be "as boring as possible" but even then, it's not clear that a "boring" language helps. What you really want in your scenario is very extensive and up-to-date documentation, both of inter-module boundaries and within individual modules. Java and C# supposedly try to make this easy, but mostly fail. The real reason they're still so popular is that they're easy to "learn" up to some not-even-barely-tolerable standard for the average cheap consultant.
  - ysleepy 5y ago
    This is short sighted. Teams do not build everything from scratch, probably most shipped executables are 90% outside libraries, open source or not. Code being predictable is a huge win, not only with other people but also with your own code from 10months ago. It also makes change more calculable.
Consultant32452 5y ago
I would submit that any language that reaches the level of adoption that Java does will be considered boring. The human mind has a tendency to prefer new/fresh things, particularly for people high in trait openness (big 5 personality traits).
- ReleaseCandidat 5y ago
  > I would submit that any language that reaches the level of adoption that Java does will be considered boring. I know of nobody who would call Javascript or C++ boring ;). Or compare COBOL (boring) with Fortran if you prefer something from the past.
  - Consultant32452 5y ago
    I don't know anyone who is excited about learning C++. The excitement around JS is trying to make it not be like JS.
gmueckl 5y ago
TL/DR: it's about readability and clarity of unfamiliar code. One problem of large codebases is that they tend to be team efforts. Given a a sufficiently large and flexible language, each team member will find their own style and idioms for their code. This creates the subtle problem that team members are unfamiliar with each other's styles and when they touch the same pieces of code, they each extend the subset of used language features by whatever is required for their favorite idioms. Eventually, the resulting code gets too elaborate for its own good and maintainability goes down. A boring, simplified language ideally constrains the team to use more or less the same patterns and idioms and this side-steps the problem.
lenkite 5y ago
Boring Is Best! When you have junior programmers joining/leaving teams, consistent, boring code written in one Boring PL according to Boring Code Conventions is like driving on a freeway in one straight direction with auto-pilot on. Clever code written in half-a-dozen Cool PL's is like driving for your life in sharply turning mountain roads with no guard-rails - something guaranteed to become cataclysmic as your number of issues/escalations rise and rise, your tech debt becomes an un-surmountable mountain and you watch your hair turn grey before you are middle-aged.
jimbokun 5y ago
> What these languages need is lots of ways to define sensible modularity boundarie One of the most important modularity boundaries is dependencies on libraries written by others. So a good, easy to use dependency manager and a straight forward mechanism for creating and sharing libraries is crucial. Java does really well in this regard.

the_af 5y ago

> regularity and good api design are much more important Do note these are more than a little flaky with many of the Java libs out there ;) There's a bit of everything, good quality and poor Java code. It's just that there is so much of it out there, that a lot tends to be crud.

throwaway2037 5y ago
Can I say one thing that is great about the JAR ecosystem -- at least in a safe "closed moat" enterprise setting? Monkey patching buggy JARs! In my experience (and many others!), it is pretty common to manage an enterprise Java project that is stuck on an ancient version of a JAR. (This can be true in any language.) If you find a bug, it might be too hard to upgrade to the latest version. But you can easily copy the source code into your project and monkey patch it. Yeah, it won't win any awards, but it keep the ball of mud rolling forward. Yes, I know this technique can be used in lots of other languages. Also, you make it sound like Java -- in particular -- has a lot of poor open source libraries. I would say the same for Perl. I wrote it for many years, and I was constantly working around tiny bugs in open source libraries. This isn't a comment on Perl or people who contribute to open source Perl libraries. Rather, this is the reality of using a huge amount open source libraries. About 98 to 99% will be "good enough". Then, you need to hack around the last 1-2% buggy bits. One thing I have noticed in general (JavaScript, Python, DotNet, Java, C++), in the last 10 years, there has been a dramatic rise in unit tests in open source libraries. Fifteen years ago, you were lucky to have any unit tests. Some of the best libraries now advertise their unit test code coverage on GitHub. It is great progress.
- the_af 5y ago
  I actually agree with all of what you say. I have done monkeypatching of that sort -- as a workaround for some bug in Apache Wicket, I forget the details -- and it wasn't elegant but it worked. Also agreed, I'm sure other ecosystems share these problems. I know nothing of Perl, but I trust you on that.
- chefandy 5y ago
  I’ve never used the jar monkey patching workflow (or gone much further with Java than some getting started guides in the 90s,) so I could be wrong, but it seems akin to opening up a new high-interest line of credit to pay down your current debt. Everyone has a plan to pay it down before the promo APR expires, but most end up making the minimum monthly payments and a year later have yesterdays debt with higher, retroactively-applied interest. Unless you know of an imminent replacement or resource boost, assuming there will be a better time to actually solve the root problem seems crazy.