Java is commonly criticized for being too verbose, but I never understood why. I agree it is verbose, but verbosity isn't really that bad of a problem. Programs aren't harder to write, they aren't more bug prone, and they aren't harder to understand. On the contrary, high verbosity means less information per token, making it easier in my opinion to read.
A good example is the anonymous class. They are portly and wasteful of vertical space, often costing 5 lines when one would due. But, the amount thinking per line is greatly reduced. In order to visually afford anonymous classes, logic must be simplified or structured, commonly by splitting up a larger function in order to fit it on a single screen. An arguable misfeature of the language has a convenient side effect of forcing best practices.
> On the contrary, high verbosity means less information per token, making it easier in my opinion to read
See I think this is actually backwards thinking. The more boilerplate you have to sift through, the more you're trying to retain before getting to what the program is actually doing.
> A good example is the anonymous class. They are portly and wasteful of vertical space, often costing 5 lines when one would due. But, the amount thinking per line is greatly reduced
Same applies for this statement. You're trying to absorb so much more code before knowing what is actually happening.
Small bugs in the implementation of boilerplate code have a tendency to sail through code reviews and go without notice until they become production issues, because experienced developers develop a habit of glossing over boilerplate without reading it too carefully.
I think that's the issue though. One should not need to have much experience in any particular language to read and understand what a particular piece of code is doing. It should be relatively intuitive. The more boilerplate a language has, the larger the cognitive load. This holds true regardless of whether or not it is invisible to anyone, it's just that much more annoying. I'm not doing a good job of expressing my thoughts here, but I absolutely "feel" this way when working with Java vs something like Python.
That being said, I'm a big of Java and the eco-system.
"One should not need to have much experience in any particular language to read and understand what a particular piece of code is doing."
I'm not sure I agree with this. I think every effort should be made to keep your code readable to others with similar knowledge. However, I don't think you need to make everything readable by a junior level coder.
Maybe a decent analogy is that not all books target a 4th grade reading level. The varience of information density isn't just about saving time for those that understand it, but also for keeping you interested (or disinterested if you aren't ready for it yet). For example, reading young adult fiction in your 30s usually wouldn't keep you engrossed.
The older and more experienced you get, the harder it is to assume others who will have to deal with the code will have "similar knowledge".
"However, I don't think you need to make everything readable by a junior level coder." I may not be a junior-level coder, but I may still be 'jr' with your particular language or framework, but have been assigned your code because you've moved on to something else.
Exactly which is why no one is going to look at all those getters and setters you added not realizing that one of the setters actually does something other than setting the field or a getter causes some side effect before returning the value.
Unlikely edge cases are the biggest source of bugs. One of the worst production bugs I've seen happened because someone refactored some code assuming a getter just got the field, like 99.9% of getters do, but this particular getter didn't.
I think you miss my point. Most people DO generate them via an IDE so they don't get looked at closely. But imagine someone then editing one of the generated methods to do something different than expected. Happens all the time.
True, but it does have impacts, like you can see less of the overall program on the screen at a time, so to scan through requires more of a look->scroll->look->scroll.
I don't think dense code has drawbacks; people measure in lines of code because they implicitly assume all lines are equal, but that's completely wrong. Reading the same logic when it's 20 lines is much, much easier than reading the same logic when it's 100 lines, because whether you can fit it on a single screen or not makes a huge difference to whether you can comprehend it.
I've worked in/with Perl. Perl is unpleasant because it's inconsistent, not because it's dense - if you want the extreme examples, compare Perl with something like APL.
Even if that were true, it still wastes a lot of space and can make reading the whole body of code more difficult. Just think about how easy it would be if Java had 2 or 5 times the boilerplate code it has now. According to you it'd be "invisible," but it'd still be a lot worse.
Ergonomics changes your design decisions. When some idiom of code or data or both is awkward to express, you'll lean naturally to something else, which may have drawbacks not related to ergonomics, like coupling or over-abstraction or duplication, etc.
Ergonomics goes into the mix of tradeoffs for design. Something like LINQ's expression trees, for example; not easy to do in Java not because ASTs can't be constructed, but because their construction isn't as ergonomic.
I think in Java this is most notable in the boilerplate it takes to create value types (and related: typedefs). This often leaks from the realm of bad ergonomics into the realm of bad design; primitive proliferation is a common problem that I believe would be less pronounced were there a more convenient way to define a value type.
Couldn't this same reasoning be used to argue that we don't need for loops or functions because we have GOTOs? Boilerplate is tedious and error-prone to write and to read/understand in my experience.
It cannot. The syntax bloat forces structural cleanliness.
A lower level problem is addressed with a higher level fix. It would be better of course to not have bloated syntax, but not at the cost of better program logic.
As for tedium: Java programmers rely heavily on IDEs to "write" most of the boilerplate for them. The IDE fills in tokens automatically, and hides them visually with +/- boxes to the side.
Personally I don't hide it, and I do type each token by hand. Since the parent brought up tedium, I wanted to mention that there are solutions to it. IDEs hide bloat, but code review and other tools often don't.
I agree. Java is one of my favorite languages partly due to its verbosity. It's easy to figure out what I was doing when looking at my code later on. It's also easier to repurpose old code.
Depends on the person I guess. I like terse code. I like pure functions. Maybe they have somehow a little cost because they can be complex, but the semantics make the reasoning quite cheap. In OO, every goddamn line is a potential nightmare.
Also, I bet 10$ that until you saw some short yet clean and expressive code, you might believe that the choice is either Java verbosity or Perl cryptics.
I agree with your general sentiment that Java verbosity is actually a strength rather than a weakness. However, the examples given in this particular article are all (IMO) cases where the verbosity truly is unnecessary and is mainly there because for backwards-compatibility. These shortcuts do not reduce readability significantly and I would love to have these in Java.
I think Java is oaky-ish. Much more commonly than core Java itself, Java libraries are being criticized for verbosity. All of those satire AbstractSingletonWorkerFactoryImpls come from real world experience. I personally see a lot of design pattern use for the sake of use without considering benefits that would bring. I see Java code happily introduce two line boilerplate to median call just to shave single line from an edge case. Scattered all over the codebase this makes business logic part of application rather verbose.
You have to create and read more tokens in a verbose language. That takes extra time, and the more tokens, the higher the odds are for bugs to creep in.
Having high numbers threads and switching between threads are different things. There is still a huge constant in front of that O(1) scheduler that makes it unattractive.
Jigsaw was what held up the Java 9 released, due to some members rejecting the proposal. It was changed and revoted upon, but it's hard to follow what was modified to make it acceptable.
Is there anywhere the design goals and constraints for modules are? I'd really like to know how they ended up in their current form.
> Jigsaw was what held up the Java 9 released, due to some members rejecting the proposal.
That was only a few weeks. If you check the official release schedule http://openjdk.java.net/projects/jdk9/ Jigsaw was supposed to be feature complete a year before that vote happened. Jigsaw was simply not close to ready when it was merged to master. And yes, Oracle still claims it hit every milestone on that schedule.
> It was changed and revoted upon, but it's hard to follow what was modified to make it acceptable.
Not much really. Basically Oracle called their bluff. At that point is was really too late as Jigsaw was already merged to master and more or less touched every part of the JDK.
> Is there anywhere the design goals and constraints for modules are? I'd really like to know how they ended up in their current form.
Not really, it was really just Oracle making things up as they went. For the past ten years Mark Reinhold would give talks at Java conferences what the module system comping in the next Java version was supposed to do and every year the content was different. For example they have no good explanation while they mashed the module declaration into a .class file, basically everybody except Oracle thinks it's a bad idea but the just went with it anyway. They claim "reliable configuration" as a goal but without versioning that's meaningless.
> They claim "reliable configuration" as a goal but without versioning that's meaningless.
Versioning is not currently built into Jigsaw, but Jigsaw provides all the building blocks necessary to support it in third-party tools.
> For the past ten years Mark Reinhold would give talks at Java conferences what the module system comping in the next Java version was supposed to do and every year the content was different.
Plus the entire development was done in the open, in an open source project with an active mailing list and frequent prototypes.
> Versioning is not currently built into Jigsaw, but Jigsaw provides all the building blocks necessary to support it in third-party tools.
If I need third-party tools to validate my dependency graph at compile time and at runtime to ensure "reliable configuration" then why do I need Jigsaw at all? That's the current state of affairs with Java already, Jigsaw provides no value.
> Plus the entire development was done in the open, in an open source project with an active mailing list
Ostensibly. There is a difference between having an open mailing list (where people could give feedback and get a superficial thank you before getting ignored) and a readonly repository and actual open development. Quite frankly I find it telling that in 2017 we have to stress that there was and open mailing list and readonly repository. The most important thing, the decision process, was completely intransparent and all Oracle/Sun internal.
> and frequent prototypes.
Which weren't useful because none of the frameworks, libraries and tools would support it.
me guessing,
i see at least two constraints that doesn't work well with a text file. The current format allows user defined annotations and the compiler find all packages of a module and automatically insert them into the module-info (you only define the exported package not all the packages).
Obeying traffic lights decreases tail latency and increases throughput. By not obeying them (as a society, rather than individual), India is only hurting itself.
> The whole western world is in for a rude awakening in the coming years with regards to retirement.
No kidding. Who will pay for all the people who didn't save? The people who did. I have very little expectation of keeping most of my money as I get older.
>Who will pay for all the people who didn't save? The people who did.
Correct. It is generally a good idea to consider all of the money being paid into Social Security to be completely wasted. I am in my early-mid 30s and I do not expect to see a dime of it. I think it will either be insolvent or subject to some ridiculous tax structure if people have earned X dollars in their lifetimes or spent too many years in high tax brackets (which I expect to in my late 30s and 40s).
Taxes will also go up dramatically as the years go by. I have a maxed-yearly Roth IRA but I also don't expect the government to keep their promise on letting me take out 100% of it tax-free despite all my contributions being post-tax. I expect to be double taxed on that, because, well, why not?
Retirement is ridiculous. It's just generally safe to assume all of your money is going to be taxed at a much higher rate and through loopholes/broken promises by the government. We face a really huge shortfall in the next few decades in public welfare programs, Social Security, and other tax-advantaged vehicles that I doubt will be honored down the line.
Just out of curiosity, what's preventing the US from implementing changes to Social Security that are sustainable? I read up on this for Norway a few months ago, and was actually pleasantly surprised at the thought that's gone into the sytem.
Norway's public pension system is now funded by every employee having 8% of their salary taxed away and earmarked to retirement. The money is placed in a broad stock and bond fund. In retirement, the earmarked amount of money for each employee is paid out in a monthly amount that matches the life expectancy of the retiree.
E.g. if the employee has paid $150.000 to the system over a lifetime of work, retires at 65 and the life expectancy for this age cohort is 10 years, the annual payment will be $15.000. The state covers for retirees that live longer, keep the money for retires that live shorter and provide a guaranteed minimum for people who reach 67 without saving up a minimum amount. To offset this, the possible monthly payment is capped with a maximum for high earners. There is also some inflation adjustment built in.
In effect, this provides a living wage for all retirees, with additional private savings required if you want to maintain a higher standard of living. The system is self-contained and is not based on younger workers paying the pensions of older workers.
>Norway's public pension system is now funded by every employee having 8% of their salary taxed away and earmarked to retirement.
Social Security payroll taxes are ~15% of salary per employee, so assuming Norway doubles the 8% (employee responsible for half, employer responsible for the other half) that's not much higher than the United States' system.
>The money is placed in a broad stock and bond fund.
Social Security is not privatized in the United States and efforts to do that by Republicans are regularly shot down. Social Security is an annuity that is tax-free and inflation-adjusted. The average ROI is about 2-4% for single, average salary employees who work full-time.
EDIT: Forgot to add, the United States excess funds in Social Security are loaned to the government for use for non-SS purposes. The government owes the Social Security program something on the order of $5+ trillion right now, which makes up over 25% of the national debt. Yes, you are reading this right. No, it is not a good thing.
You could argue that Social Security could do a lot better if citizens were allowed to control that money or if it was simply invested in a total stock/bond market index fund, but then you'd be incurring significant risk as well.
>In retirement, the earmarked amount of money for each employee is paid out in a monthly amount that matches the life expectancy of the retiree... The state covers for retirees that live longer, keep the money for retires that live shorter and provide a guaranteed minimum for people who reach 67 without saving up a minimum amount.
This is basically how it works in the United States, except:
> To offset this, the possible monthly payment is capped with a maximum for high earners.
This is likely to happen in the United States as the country moves more economically liberal (current administration excluded, but even Trump has some economic policies that old-timer conservatives would never agree to). We currently don't have this. But taxes and fees and other such efforts will be successful against the rich soon enough here.
>The system is self-contained and is not based on younger workers paying the pensions of older workers.
This doesn't really make sense. Your example describes this to a T.
Tell me: What happens when the "broad stock and bond fund" collapses in a thirty-year low for a period of six years and pension promises far outpace receipts? Who will pay for this? The state will cover, correct? Well, that's younger people paying for older people no matter how you slice it.
>>Norway's public pension system is now funded by every employee having 8% of their salary taxed away and earmarked to retirement.
In general this how any pension scheme is supposed to work. Except that it doesn't. When you start to add things like exceptions whole scheme starts to come apart after a while.
Pensions are one of those things which are ripe for abuse. Also you need to start looking at other benefits that come along with it like health care. Then there are unions that graciously award over time work to employees to drive up their compensation in the last few years of work.
There are also other things going on like inflation adjusted pensions.
In India there was a recent drive to include One Rank One Pensions for armed forces, which demands pension revisions every single year based on last highest pension paid in that rank for that year.
It's not retirement that's ridiculous, it's that old people have a vote in this and because that vote is so overpowering, no-one will even try and fix the issue until it's too late.
Double taxation is extremely unlikely, and would likely have to be of the form of applying a tax to earnings in the Roth IRA or something like that. Which is how other investment-related income is taxed anyways so, I don’t know.
Additionally, SS pays out at 75% of projected levels at the height of the retiree crunch, so assuming the program will just vanish is not something a lot of financial advisors are going to consider. Given the universe of possibilities, the one that doesn’t result in people with pitchforks is probably the one that we will go with. We could also solve this problem today with a 1.8% addition to the payroll taxes, removing means testing, etc. It’s a problem to be solved but expecting the world to burn in the process of solving it, the magnitude just isn’t there. Makes for good fan fiction though :-).
>>and would likely have to be of the form of applying a tax to earnings in the Roth IRA or something like that. Which is how other investment-related income is taxed anyways so, I don’t know.
Correct, this would be a huge breach of trust by the federal government. Which is nothing new, obviously, but....
There's some business-related reasons why I don't (I don't yet make enough money in salary for it to matter wrt deductions) but also because I think taxes will be very high when I retire and that my Roth will be taxed at a relatively low rate, subject to some "fees" or something.
I think the Roth will still exceed the value of a traditional IRA (plus it's only $5500/year, hardly huge as I get older and my net worth increases), but I would be willing to bet that the Roth IRA will not exist in the form it does in 20-30 years, and that existing ones will be subject to a tax/fee to make it "fair."
Depends how history plays out in the future. If people who save end up paying for people who didn't, it implies one of three things: 1) financial panic 2) inflation or 3) taxation.
All of these are fairly likely, but looking back at history, there are a number of other possible futures that would take care of the problem. Mass plague, where all the old people die off. Mandatory euthanasia, where the government kills all the old people. War or anarchy, where both young and old die indiscriminately. Colonizing other planets, which opens up vast new resources. Mass automation of health & elder care, so the robots pay for the people who don't save.
The depressing thing is that most of these are pretty horrible, and the two that aren't - automation and spaceflight - are probably the least likely. But then, history is filled with black swan events that open up human frontiers that nobody could've imagined. Maybe one of them will save us.
Or like it worked in most socialist economies which gradually migrated to free market in the 90s.
Older people make painful sacrifices to merely survive. Younger population doesn't care, and largely thinks the old deserve it for not being serious about their retirements in young age.
Social security in that situation will largely depend on continuing to work in old age, and surviving on bare minimum money and at worst depending on kids and friends.
War and anarchy aren't feasible in old age, when you get knee pain for walking across the street. The whole thing will be bad, its just people have to deal with it and move on.
It wouldn't actually matter. The problem is demographic, not financial.
Ultimately, somebody has to produce the resources, goods, and services that every person on earth needs to survive. If people live an average of 5 years after retirement, work for 50 years, and the population is at a steady-state, then every elder is supported by 10 workers. If the population has doubled in the last generation, then it's 20 workers. If the population is still doubling but people are now living for 10 years after retirement, then it's still 10 workers/elder. If the population returns to a steady-state but people now live for 20 years after retirement, though, we're down to only 2.5 workers/elder. Suddenly everybody feels the pinch.
Pensions, 401ks, stock market growth, and all other forms of retirement savings are just different ways of lying to ourselves. Ultimately, goods have to be produced, services have to be rendered, and money is just a way to track who has done that and reward them appropriately. If you have fewer people doing the work and more people depending upon it, standards of living will fall.
If I had to bet on a (peaceful) solution, it would be automation. Do more with less and a given number of workers can support a much greater number of dependents; the only challenge then becomes redistribution in a way that people find adequately fair. But elder care has proven stubbornly resistant to automation: if you've ever had a family member in their 90s and tried to take care of them at home, you may be doubting that it's even possible for 2.5 workers to take care of one elder, even if their own needs were completely automated away and they had no children.
"It wouldn't actually matter. The problem is demographic, not financial."
It's interesting how many people don't understand (or don't want to understand) this.
Money is just a number, is real resource what is important.
Never mind how many savings the people have, if there are not enough people or resources to do the necessary jobs.
And, the other way works too, never mind how many old people there are without savings, if the productivity is enough to take care of them easily.
The obvious conclusion is that, instead of caring about money "saved", we should be caring about getting more productive. That would mean improve technology, increase knowledge and training.
My problem with "getting more productive" is that the gains nowadays are achieved through automation (capital investment in general) which pretty much guarantees that the gains from the increased productivity are captured by the capital owners. So even if we double the productivity of the economy, there is no guarantee that this will improve the lives of most people who depend on salary or pension. There must be some form of redistribution to allow sharing the gains of productivity but this has been a taboo in the US (and many more places) since the 80s and I don't see this changing anytime soon.
Even if it were a problem or resources, the solution is invest now in creating more resources, not in "saving money".
I think that part of the reason it's a taboo, is because the officially pushed narrative is designed to hide that, in many instances, is a problem of redistribution more than a problem of resources.
For instance, in USA, the "public debt crisis problem", that it's mainly meaningless, distract from a honest debate of the real issues.
> That kind of runaway automation that could pay for this kind of a party isn't close
Automation is already here, and has been for a long time. The whole point of the industrial revolution is about automation: Machines that support or replace human workforce.
The explosion in availability of computing power in the last two decades put automation into overdrive, and I don't see it slowing down.
Meanwhile, the gains of automation do not directly translate in inproved wealth for all members of society.
For example, if a company replaces 50% of its workforce with machines, they might make more money because they save on salaries, but effectively worsen the situation for the pensions of the layed off people.
This idea is not without drawbacks. Mandatory pension systems have a history of being wiped out by extinction events both governmental (USSR et al) and corporate (Kodak and other midcentury megacorps).
It's at least something I guess, but retirement planning is a really really long forecast horizon and is inherently risky.
In Germany the retirement system is far from perfect - but it at least keeps (most) people from being homeless or starving.
The lack of universal health insurance in the USA is basically traceable to the same societal shortcomings. Why should a rich banker support with his premium health insurance for a woman who gets pregnant - as he's not getting pregnant anyway. That's a very egoistical way to look at communal cooperation but at the end of the day the reason for why ACA is being sabotaged by many politicians.
I assume by "woman" you meant someone who is at or below poverty line, if so, I (and most people) don't have a problem chipping in.
The point you are missing is that right now, 90% of the US population cannot afford to pay for child-birth (or any other medical procedure) themselves (out of pocket), as they typically cost $20K and up.
With a reasonable market- (or single-payer-) based health-care system, most people (except for the poor and almost-poor) would be able to pay for their own health care. The current "system" in the US is a scam of major proportions.
Lip service benchmarks like this don't help anyone. They just add fuel to the ignorance fire. Why was the Go version faster? Without profiling the code being benchmarked it doesn't really mean anything, since any number of unrelated factors could have affected it.
For example, did you know that until recently Go's HTTP/2 client didn't do flow control? Sending cross continent requests could easily result in slowness. Did the Go program in this test use the updated code? If not, it may have been much faster. See how not understanding why it's slower leads to not understanding?
.NET may actually have been faster, but we won't ever know because the author didn't really understand what was going on.
I totally agree.
The author of the Iris web framework, which also is the author of this article, never gives us the reason why Iris is "The fastest web framework for Go in (THIS) Earth" which he insists in the Github repository.
Assuming that his insistence is true, I want to know how he made the performance improvement compared to other Golang web framework.
A good example is the anonymous class. They are portly and wasteful of vertical space, often costing 5 lines when one would due. But, the amount thinking per line is greatly reduced. In order to visually afford anonymous classes, logic must be simplified or structured, commonly by splitting up a larger function in order to fit it on a single screen. An arguable misfeature of the language has a convenient side effect of forcing best practices.