Economist's View: "The Mathematics Generation Gap" - <AUTHOR> http://economistsview.typepad.com/economistsview/2011/05/the-mathematics-generation-gap.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EconomistsView+%28Economist%27s+View+%28EconomistsView%29%29&utm_content=Google+Reader <comment><USER4> The points brought up here, especially by Thoma but less so by the quoted passage by Woolley, are very valid in my experience. Often times the shortest way surpass a difficult abstract challenge is to find a practical instance of it and then slough through the mechanics. You abuse the natural pattern searching of the human brain very productively that way.

Simultaneously, these arguments tend to be reactionary and ignore the benefits of calculators. A calculator, use effectively, allows for a far larger number of examples to be considered together than the brain is often able to achieve. This is was most apparent for me in pre-calculus classes where students should be gaining abstract intuition about the behaviors of functions. Here, graphing large numbers of functions varying their parameters allows one to quickly get a sense of a parametric family.

There's an implicit statement here that the "gap" is one such that the lower generation is worse off than their elders --- which is a pretty common human narrative, really. I think instead that this difference is less well-ordered than assumed. Technology is definitely capable of improving human cognition and learning by providing new capacity, and curricula need to explicitly study and take advantage of these capacities.

<comment><USER5> The argument though is that it is simply impossible to use a calculator effectively without first understanding the basics.

If you don't understand that 50*80 should give you something starting with 40, you don't even understand that getting 3745 as an answer on your calculator because you mistyped is horribly incorrect.

You can chalk it up to "kids these days" all you want, but if you do some basic math problems with a 60 year old the odds are they will simply leave you in the dust while you go looking for a calculator.

<comment><AUTHOR>
        > The argument though is that it is simply impossible to
        > use a calculator effectively without first understanding
        > the basics.

I don't think that's the case. I think the author is perfectly happy that people know how to use the calculator. I think the point is that without working through the basics underneath, mind-numbingly repeatedly, you don't gain any real insights about what's going on.

It's certainly true for me. Many's the time, when I've had monster power under my fingertips, that I've brute-forced solutions and failed to gain any insight. Then I've worked a few small, single instances by hand, and realised that there was structure I hadn't seen before.

The pattern-matching, pattern-finding parts of the brain are phenomenal. Sometimes they are best exercised by getting machines to produce loads of examples, and loads of visualisations very quickly.

Sometimes they are better exercised by working tedious examples by hand.

Balance.

<comment><USER6> _I think the point is that without working through the basics underneath, mind-numbingly repeatedly, you don't gain any real insights about what's going on._

I don't think that's true. And I'll say something controversial. Programming is taught more effectively than math and its because you don't spend a lot of time mind-numbingly repeating the basics.

Half the people on HN recommend teaching with Python for just this reason.

And think about it, when you teach programming do you make your student walk through what every instruction does? When I learned recursion, I walked through fib(n) by hand -- once. That's the sum total of how many times I've done a full hand expansion of a recursion in my life. How many times have I run a full program on paper with the substitution model? Never. How many times have I iterated even a small loop by hand? Never. These are concepts that I understand as well as anything that I know, yet I've never "mind-numingly" worked through them by hand.

A lot of traditional math teachers want us to sit down with an instruction pointer, stacks, heaps, physical/virtual pages, laid out and have us repeatedly simulate program. That's really the mathematical equivalent of doing this rote computation. I say teach them the concepts and give them interesting and challenging problems that make use of the concepts. The concepts will stick better, they'll learn faster, and they'll be more engaged.

<comment><USER7> This is even true in college, where for example a large part of a physics education is spent computing integrals and solving differential equations in special cases, using approximation methods by hand. It would be more appropriate for an intuition of the physics to use symbolic and numerical methods on a computer a lot more. You realize that doing arithmetic by hand is a largely pointless exercise when you get a calculator, and we should similarly recognize that doing integrals and differential equations by hand is largely futile when you have things like maple and scipy.

<comment><USER8> I can tell you right now I'd never hire someone who wasn't able to compute the result of a linear differential equation without using a computer, because it's something that every person I hire needs to do very frequently while designing circuits. The difference in quality of design between one who can analyze a circuit on paper or in the head and one who relies on simulation to discover basic properties of the circuit is massive. Iterated simulation is not a tenable approach to the design of any sufficiently complex circuit.

Moreover, the nature of innovation in my corner of the mixed-signal circuit design world is such that said innovation rarely (if ever) comes as a result of a computer simulation. Much more likely, a person with a deep understanding of the fundamental underpinnings of his/her particular problem gains insight into its solution as a result of the same experience and intuition that leads to the aforementioned understanding.

I can have a computer calculate Fourier transforms for me all day, but it's vanishingly unlikely that any amount of such calculation will lead me to the kind of insight that sparked the invention of CDMA.

<comment><USER7> It is definitely useful to be able to do linear differential equations by hand. It's not useful to keep doing these things by hand. Just like it's useful to know the algorithm for multiplying two numbers, and it's not useful to keep doing multiplication by hand.

What lets people invent new circuits is their good intuition about circuits, _not_ their ability to solve linear differential equations quickly by hand or to compute integrals by hand. When an expert is analyzing a circuit on paper he is thinking about "what happens if the input to this circuit is a sine wave with high frequency", he's not going to solve the differential equations by hand.

Rather than circuits look at how electromagnetism or quantum mechanics is taught in college. In my case it was integrals, integrals, integrals. Doing these by hand provided approximately zero intuition into the physics. We could have covered more ground if the instructor would just type these into maple, instead of doing them on the board or in the book by hand. Or how many times have I not had to compute eigenvalues of 2x2 or 3x3 matrices. How many times have we not applied crude approximations in class because doing it by hand was too difficult, when typing it into a compute would give you 100 digits of precision in a couple of milliseconds. One time one of my maths teachers how to compute tan(2) or something like that by hand. After half an hour of calculation he had 2 digits. Computing the integral of something to a crude approximation in an edge case strikes me as futile as computing tan(2) by hand.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> "Conrad Wolfram says the part of math we teach -- calculation by hand -- isn't just tedious, it's mostly irrelevant to real mathematics and the real world. He presents his radical idea: teaching kids math through computer programming."

[http://www.ted.com/talks/conrad_wolfram_teaching_kids_real_m...](http://www.ted.com/talks/conrad_wolfram_teaching_kids_real_math_with_computers.html)

<comment><USER10> Y'know, maybe what we should really do is to completely decouple "mathematics" from "arithmetic". Arithmetic is useful but boring and you mostly learn it from age 5 to 12. Mathematics is harder, more interesting, and either useful or useless depending on what you eventually do with your life (no doubt 60% of people could go through life without understanding any mathematics at all -- all they need is arithmetic).

</comment></comment><comment><USER11> Tangentially, up until grade 6 or 7 (in the late 80's), my math books also included BASIC code related to the concepts --- usually at the end of the chapter. It's how I became curious about programming and more so about math (though in my case none of the teachers ever did anything with the material, I either just typed the code into my family's TI-99A or tried to mentally work out what the program was doing).

<comment><USER12> That's amazing, I wish any of my math books had that; we would probably see a lot more young programmers these days. I can seriously say that the only reason I even got into programming was discovering TI-Basic in 7th grade (although the habits it taught me had to be slowly unlearned as I started using a real language ;)

<comment> T-hawk Well, the entry barriers to programming were actually lower in the 1980s. Pretty much every home computer came with a flavor of BASIC built right in to ROM or at the worst bundled with it on a disk. Anybody with a TI-99/4A, C64, various Apples, Atari 400/800/ST, or many others could jump right in to that kind of programming.

What's the equivalent nowadays? Windows doesn't really come with any programming environment. There's no standard for those math books to write towards. Yeah, there's plenty of free compilers for any language, but the funnel from even knowing they exist, to having a reason to get one, then finding it, and downloading and installing, gets pretty lengthy and technical for your average seventh-grader or whatever.

Heck, I would argue that TI calculator BASIC is the closest thing we have to a universally available development environment for secondary students today.

<comment><USER13> Every desktop of laptop OS I know of comes with at least one JavaScript interpreter installed.

The real problem is the growth of phones and tablets as preferred client devices; while the JS interpreter is still there, it becomes a challenge to enter and run the code.

</comment></comment></comment></comment><comment><USER14> Back in the 90s there was an episode of the Outer Limits that touched on this subject. Effectively there was a nexus of information that everyone connected to through their minds. Anytime they wanted to know something, they just looked it up by thought and presto, instant expert. One guy couldn't connect, so he had to learn things the old fashioned way by research and practice. Naturally, the nexus goes down and people can barely function. He goes from being the village idiot to the village savior.

<comment> mkr-hn There's an Asimov story similar to this: <http://en.wikipedia.org/wiki/Profession_%28short_story%29>

<comment><USER15> Also, "The Feeling of Power".

[http://www.themathlab.com/writings/short%20stories/feeling.h...](http://www.themathlab.com/writings/short%20stories/feeling.htm)

</comment></comment></comment><comment><USER16> The crux of the issue as I see it is an extension of what mathematics educators call "number sense." (<http://en.wikipedia.org/wiki/Number_sense>)

It seems from many of the other comments is that people recognize that performing exact mental-arithmetic calculations is rarely necessary; however, the more intuitive understanding of how numbers relate in magnitude etc. is critically important. Estimation is something that I think many of us take for granted, but that has some significant mental pre-requisites.

Interestingly, a growing branch of mathematics education has been working to explore whether the traditional rote memorization is the most effective way of instilling this more hollistic understanding of numbers. If people were interested, I could ask some educator friends for more up-to-date links/citations on this topic.

</comment><comment><USER17> Seems to me there was an article a few months back on how the use of GPS in cars was handicapping drivers -- damaging their ability to form and manipulate abstract mental maps.

I'm of the opinion that you should always learn the thing at about two levels down in automation from where you normally use it. So, for programming, I'm all for assembler, compiler, and C programming skills, even though those might never be used in the real world. By the same principle, if you're learning navigation in an airplane, you should learn dead reckoning and a wet compass. If you're learning to driver and shoot a tank you should have pretty good concepts of how rifle combat works, etc.

In math and economics, however, I'm not sure what "2 levels down" means. Is math the rote memorization and repetition of stuff? Most definitely not. But does it depend on it? Maybe. Is it the application of pre-existing patterns in any fashion -- such as punching numbers into a calculator? I don't think so. I think it's much more about the ability to teach yourself to find and exploit patterns through trial and error. That's one of the reasons I've always thought so highly of High School Geometry classes -- when done well, they begin to teach _how_ to think, not just what to think.

Food for thought.

<comment><USER5> In my mind, math is a language like any other. Whereas you wouldn't be considered fluent in English until you have memorized a significant number of words and phrases, the same holds for mathematics.

Al that rote memorization that everyone hates is the same as understanding a basic sentence.

<comment><USER18> What rote memorization?

</comment></comment></comment><comment><USER19> I think the problem with Economics in this case (I'm an undergraduate) is that it has become overly mathematical, often for its own sake.

A great article to read is here: <http://www.jstor.org/stable/30042661> \- much of UG level Economics can be taught and explained with the use of diagrams and graphs.

Overall, I think the generation gap argument is fairly sound - we aren't taught in the same way that our parents and their parents were, and for better or worse, this is how it is.

<comment><USER20> I like the way Sowell did it (recounted in his _A Personal Odyssey_ ); when teaching economics to engineers he concentrated on a "literary" conceptual teaching style, since he already knew they were competent in the needed math.

Presumably, though he didn't discuss this directly, he used more math with those who needed it to understand the mathematical underpinnings of the theories.

His idea was to present the coursework in a way that would make the students think about what they were doing. As he put it about the engineering students, if he presented it in the regular mathematical way, they could have just plugged the numbers into the formulas without necessarily understanding what he wanted them to learn.

</comment></comment><comment><USER21> I remember doing "Mad Minutes" in Grade 4 (1986). We'd have to do 30 multiplication problems (up to 12 * 12) in 60 seconds. It was a game to see how many we could complete.

I think I might need to revive these for my technical-college math students.

<comment><USER22> About that Mad Minute.... Sure it may be great for for kids that are already good at it. The fact that you thought it was a "game" says a lot.

But for kids that haven't gotten the fluency with the arithmetic tables yet it just raises their anxiety level, even to the point of near-panic. Which of course shuts down exactly those parts of the brain that you need to be running well to be good at math. The anxiety association with math becomes the lesson learned and as a result students can end up absolutely hating math because they feel sure that "I'm just not good at it".

Of course, it could be a fun experiment to try on some college students.

<comment><USER5> _it just raises their anxiety level, even to the point of near-panic._

If a child is this adverse to a simple competitive math challenge, (or any competitive challenge) the problem is much larger than hating math.

Not everyone takes to math, but not everyone takes to reading either. Both skills are essential to a certain level to function properly in our world. You wouldn't suggest that a child who finds reading difficult not be expected to read a novel, so I'm not sure why there is such aversion to multiplication tables.

Even if all the child does is mesmerize the patterns, they've still learned a useful construct that will serve them well for the rest of their lives.

<comment><USER22> You seem to think I'm against working hard on multiplication tables - I'm not.

What I'm saying is this particular test is notorious for turning borderline kids into outright failures. I spoke with an educational PhD specialist about it once.

There are issues here of personality, temperament, and biology. If you haven't experienced it yourself or seen it up close, it's very hard to appreciate but very easy to think that you do.

Think of a skill that takes a significant amount of _gentle, enjoyable_ practice - until it clicks. Like whistling or riding a bicycle. We wouldn't expect kids to learn to whistle or bicycle by having daily contests to see who could whistle the most notes or bike the fastest in 3 minutes, would we? No, the kids who hadn't got the hang of it yet would simply be repeatedly crashing and burning in front of their peers.

Whistling and biking are relatively easy to pick up once you have the physical maturity, but the development that enables math kicks in over a range of several years in different people.

This is also the time the kids are developing likes and dislikes and academic self-image. At this age, it's better to learn to _like_ math and to enjoy the experience of new concepts sinking in. Pressure drills which tend to exaggerate and reinforce differences can be downright harmful for elementary school kids.

<comment><USER21> Yes, this is a concern. You wouldn't expect someone to compete athletically without training first.

I like the "gamification" aspect, and would prefer to frame this as self- competition.

The same "being beat down at math again" reaction can be turned around into "OMG I'm getting better at math" with some empathy and debugging. It's a wonderful thing to see.

I have students who can't do exponents and have trouble answering 3 x 5. We're trying to teach them symbolic and linear algebra. Dur. No wonder they can't keep up.

I can debug the exponents deficits (integer exponents) in about 3 hours with a small group. Perhaps another session for radicals and fractional exponents.

It's somewhat addictive, to see them realize "I don't have to suck at math".

<comment><USER22> _The same "being beat down at math again" reaction can be turned around into "OMG I'm getting better at math" with some empathy and debugging. It's a wonderful thing to see._

It really is.

 _I have students who can't do exponents and have trouble answering 3 x 5. We're trying to teach them symbolic and linear algebra. Dur. No wonder they can't keep up._

I think the thing to keep in mind is symbolic math and 3 x 5 are almost completely different tasks.

We lump them together under "math" but I've met many teachers who are excessively attached to these false dependencies.

I'd love to bring back Euclid himself and sit him down in one of these third grade classrooms and see how he does on the Mad Minute. It's not like he knew how to do long division or anything. :-P

 _I can debug the exponents deficits (integer exponents) in about 3 hours with a small group. Perhaps another session for radicals and fractional exponents.

It's somewhat addictive, to see them realize "I don't have to suck at math"._

Thank you for what you're doing.

</comment></comment></comment></comment></comment></comment><comment><USER23> From the original article 'Students today might be taught by a teacher who is himself unable to work out 37+16 without help' I take it that this is extreme exaggeration to make the point. Such a person would clearly not be fit to teach any subject let alone one requiring numeracy skills at its core.

<comment> mkr-hn I think most people who seem unable are just unwilling. I can do that in my head, but it's a lot of effort without practice. Someone less patient might put "37" and "16" in their mind, start adding, and interpret the block they hit when trying to carry the 1 as "can't do it."

It's hard to imagine not being able to do it if you're practiced, but it's as hard to do as anything else you never have to do when you never do it.

</comment></comment><comment><USER24> Conservative generation gap nonsense. The prevelance of Google Maps means people can't plan directions and hence can't read some graphs?

Ban television, radio, electric lights, the horseless carriage, automated looms, steam engines, the printing press, and writing while you're at it.

This sort of "the basics are really important" nonsense is sometimes heard from the old directed at the young because they can no longer argue against calculators themselves, so they make a proxy.

</comment><comment><USER5> The big issue here, since most reading this are probably of the generation in question, is found in the first comment:

 _As a result they have no quantitative intuition, which means they have no idea if their arithmetic results (achieved by simply hitting buttons on a keypad) even make sense._

That's scary. It'll be quite difficult to teach my kids math if their own schools don't see it as a requirement.

<comment><USER25> I think we should aim for "quantitative intuition" by teaching how to do rough calculations instead of spending time teaching precise calculations.

There is a lot of "cheats" possible when calculating approximations that makes it much easier to learn/perform.

In real life there is often so many uncertainties in the source numbers that a 'precise' answer is not meaningful anyway. Many people think that all the digits displayed in the calculator are significant/meaningful.

If you are a painter that estimates an offer price to the customer, you don't need to be able to work out in your head that 10.5 * 21.5 is 225.75, the estimate 'approx 215-230' is almost always good enough.

<comment><USER5> _I think we should aim for "quantitative intuition" by teaching how to do rough calculations instead of spending time teaching precise calculations._

This is like saying we should teach children how to swim by letting them splash around in the wading pool.

 _In real life there is often so many uncertainties in the source numbers that a 'precise' answer is not meaningful anyway._

Math is precise. That's the whole point of it. I don't want my banker, accountant, civil engineer, pilot, cartographer, or architect working on "good enough". I want them to be precise. Consistently.

<comment><USER26> "Math is precise."

Your brain is not. I've seen a lot more evidence of people bootstrapping from intuition up to mathematical precision than simply starting with mathematical precision. Taken to its logical conclusion (and I do mean that I believe this is the _logical_ conclusion), this leads to trying to teach number and set theory to kindergarteners, berating them for failing to get it, throwing your hands up and declaring they just aren't suited for math. You _have_ to start with quantitative intuition, the alternative is not to teach math at all. There isn't a "start them out on correct pedagogy immediately" choice. You can and should argue about what tradeoffs are best, but you will have to have tradeoffs.

<comment><USER5> I don't seen how quantitative intuition and precision are somehow opposed to each other. 4*5 is 20. Not 21. Not 18. 20.

That is logical, and it's vitally important in the understanding of all future concepts. You don't need to understand advanced calculus to grasp the concept that 2 3/4 oranges + 2 1/3 oranges is not 5 oranges altogther, but actually more, and that left over bit is in fact meaningful and relevant.

It's when you start to play with abstractions that mathematics becomes confusing, not when you are being precise.

<comment><USER27> When is the last time you had a use for exactly 1/12 oranges?

"some bit more than 5" is plenty of precision for nearly any conceivable situation in which your example could appear.

[https://secure.wikimedia.org/wikipedia/en/wiki/Significant_f...](https://secure.wikimedia.org/wikipedia/en/wiki/Significant_figures)

<comment><USER5> I think you misunderstood my example. My point was that knowing that there is 5 1/12 oranges (as opposed to 5) is the important precision, and it works logically to a child's mind.

It's quite a bit more complex to expect the child to discard the 1/12 and suggest there are 5 oranges. It's not that the 1/12 is useful for anything, it's the fact that it exists, and is accounted for.

</comment></comment></comment></comment></comment></comment></comment><comment><USER28> Don't blame this on affordable technology.

It is the curriculum.

<comment><USER29> I agree - calculators have been generally available for a _long_ time, well over 30 years.

<comment><USER30> _calculators have been generally available for a long time, well over 30 years_

Thirty years before 2011 is 1981. That's not true of graphing calculators generally being in the hands of high school students. By that year, many engineering students at university had calculators that could do calculus (usually with a "solve" algorithm) but the graphics plotting was just beginning for hand-held devices for university students. I was alive and studying math in the relevant years. Four-function or "scientific" calculators in K-12 schooling were just coming in during the 1970s.

After edit: while I disagree that calculators have been pervasive and encouraged in either elementary education or higher education for much longer than thirty years, I agree with the (grandparent?) comment that the curriculum in K-12 mathematics in the United States is lousy, and has been lousy through at least three different eras of curriculum fads, calculators or no calculators. The curriculum is indeed the key issue. Calculators are a useful tool, and today they belong in K-12 and in higher education. For a classic comment on how much calculator technology has progressed in the last fifteen years, see

<http://xkcd.com/768/>

<comment><USER28> In my elementary school, we had math superstars. These were math teaser problems.

One week, one of the problems actually required the use of a calculator (it was specified in the problem).

I remember my father taking me to RadioShack, where he purchased a calculator for me, only to solve this one particular problem.

This was in 1986. This one is from 1976...

[http://cgi.ebay.com/Vintage-Radio-Shack-EC-490-Scientific- Ca...](http://cgi.ebay.com/Vintage-Radio-Shack-EC-490-Scientific-Calculator- Case-/290571906416?pt=Calculators&hash=item43a76f6d70)

Math Superstars link: [http://it.pinellas.k12.fl.us/schools/curlew- es/studentconnec...](http://it.pinellas.k12.fl.us/schools/curlew- es/studentconnect/mathsuperstars/mathss.html)

</comment></comment></comment></comment><comment><USER31> I see the lack of mental arithmetic ability all the time when scuba diving. There are many experienced divers who are totally dependent on wrist computers or pre-calculated tables, and can't do simple things like figuring out decompression schedules or gas consumption rates in their heads. If you have a good sense of numbers then it's really easy to do these things in your head after you memorize a few simple rules. Yet so many divers think it's some kind of black magic, or even that it's somehow "dangerous" to make your own calculations.

<comment><USER32> It's a good idea to keep a table and a wrist calculator when scuba diving anyway, in case you're subject to nitrogen narcosis, which makes you really stupid.

<comment><USER31> Nonsense. It's a good idea to not do stupid things like breathing narcotic mixes at significant depths.

<comment><USER32> Did you actually dive at sea? You may feel the narcosis at varying depths, depending upon the temperature, your fatigue and some other parameters. You may usually dive at 50m breathing ordinary air without problem, and some other day get completely stoned at 40m. This happens sometimes, particularly when you dive for the first time after the winter break for instance.

<comment><USER31> I was diving at sea last weekend. I don't dive air at 40m. Your other comments about narcosis are sheer nonsense, completely off base. Don't breathe narcotic mixes.

<comment><USER32> > _I was diving at sea last weekend. I don't dive air at 40m._

Good for you. In France, you're allowed breathe air down to 60m. Most people commonly breathe air down to 40/50m, or did so recently enough.

> _Your other comments about narcosis are sheer nonsense, completely off base. > Don't breathe narcotic mixes._

My oh so numerous comments about narcosis? What are you talking about? Instead of giving condescending lessons, would mind explain what you mean?

<comment><USER31> I don't care what's "allowed" or not. Where I dive there are no scuba police to tell you how deep you can go or what gasses to breathe. There is no evidence that most divers breathe air down to 50m. What you subjectively "feel" about narcosis has little relevance to what's actually happening in your body or how impaired you are. As for your comment about feeling "stoned" the first time diving after a break you seem to be implying that divers can somehow adapt to narcosis over time, which of course is completely wrong. [http://www.us.elsevierhealth.com/product.jsp?sid=EHS_US_BS-S...](http://www.us.elsevierhealth.com/product.jsp?sid=EHS_US_BS- SPE-954&isbn=9780702025716&lid=EHS_US_BS-DIS-1&iid=null)

I am being condescending because you are posting dangerous misinformation in a public forum. Divers who believe those lies and fairy tales tend to end up hurt. If you don't know what you're talking about then it's better not to post at all.

<comment><USER32> > _I am being condescending because you are posting dangerous misinformation > in a public forum. Divers who believe those lies and fairy tales tend to end > up hurt. If you don't know what you're talking about then it's better not to > post at all._

I didn't know that people came to HN to learn about diving. On the other hand, they go to wikipedia, where you should have a look.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER33> It is a difficult issue. I do a mathematics and computer science degree hence there's obviously no real lack of mental arithmetic maths skills for this degree (well, at least the basics are consistent across the maths students).

Anywhoo, this is - IMO - something that the author's college should look at collectively. If there are some students and professors with massively different ideas of the required level of mental maths skills, perhaps the college should look at introducing a mandatory first year 'mental maths' crash course/module?

This would help to make things a little more consistent. If there's genuine confusion/disagreement between the students and Professors, this should - <USER2> - be addresses by a course-wide decision being made.

Regarding programmable calculators - they can be reset in about 2 seconds total (it's usually Menu -> Settings -> Memory -> Reset All).

In our University, the exam invigilators ensure that all programmable calculators are reset (with them watching them being reset, of course) before the start of the exam.

So I'm not sure why this (to me) fairly obvious idea seems to be overlooked in the article? As I say, it takes 2 seconds total.

An interesting article though; even though I think the author/prof is approaching things in a slightly muddled (for want of a better - <USER3> insulting- term!) way. The college should (IMO) decide on how they want to approach things, and then be consistent across all modules and all Professors.

</comment><comment><USER34> Skills become outdated over time. The skill of mental calculations, I think, is not really that valuable on the average nor is it unlearnable later on if you sit at a cashier's desk at some point ... but the skill of doing _quantitative_ calculations mentally greatly helps me make connections that I suspect I won't make otherwise. I think this is because I'm morphing pictures in my head instead of crunching numbers.

Next step - lets allow all kids to use google search during their tests.

</comment><comment><USER30> There has been a profound change in mathematics education in the years indicated, and the author of the submitted article is on to something. One of my favorite authors on mathematics, Professor John Stillwell, writes, in the preface to his book Numbers and Geometry (New York: Springer-Verlag, 1998):

"What should every aspiring mathematician know? The answer for most of the 20th century has been: calculus. . . . Mathematics today is . . . much more than calculus; and the calculus now taught is, sadly, much less than it used to be. Little by little, calculus has been deprived of the algebra, geometry, and logic it needs to sustain it, until many institutions have had to put it on high-tech life-support systems. A subject struggling to survive is hardly a good introduction to the vigor of real mathematics.

". . . . In the current situation, we need to revive not only calculus, but also algebra, geometry, and the whole idea that mathematics is a rigorous, cumulative discipline in which each mathematician stands on the shoulders of giants.

"The best way to teach real mathematics, I believe, is to start deeper down, with the elementary ideas of number and space. Everyone concedes that these are fundamental, but they have been scandalously neglected, perhaps in the naive belief that anyone learning calculus has outgrown them. In fact, arithmetic, algebra, and geometry can never be outgrown, and the most rewarding path to higher mathematics sustains their development alongside the 'advanced' branches such as calculus. Also, by maintaining ties between these disciplines, it is possible to present a more unified view of mathematics, yet at the same time to include more spice and variety."

Stillwell demonstrates what he means about the interconnectedness and depth of "elementary" topics in the rest of his book, which is a delight to read and full of thought-provoking problems.

<http://www.amazon.com/gp/product/0387982892/>

I have a collection of analytic geometry and calculus books, accumulated as used books from various readers, that includes the books used by my late father in his higher education as a chemistry major during the Truman administration, followed by books from other previous owners reflecting "new math," "back to basics," and "reform" approaches to mathematics education. Plainly today's secondary and tertiary students of mathematics need to take advantage of current technology so that they can devote more time to THINKING about the mathematics they learn and less time to what even any mathematician would call "tedious calculation." But too few students have ever been guided to through the kind of insight-producing problems in which the tedious steps themselves and the false starts while struggling with the problem produce deep understanding. Stillwell gives examples of such problems in his books, and the minority of students who participate in math contexts or who voluntarily work the "challenge" problems not assigned in their textbooks may gain such insight, but most school textbook problems of all eras are mere exercises, and too few students do enough of those thoughtfully to have hope of learning mathematical concepts.

See "Basic skills versus conceptual understanding: A bogus dichotomy in mathematics education," American Educator, Fall 1999, Vol. 23, No. 3, pp. 14-19, 50-52 for additional commentary on mathematics education,

[http://www.aft.org/newspubs/periodicals/ae/fall1999/index.cf...](http://www.aft.org/newspubs/periodicals/ae/fall1999/index.cfm)

and see an earlier HN comment

<http://news.ycombinator.com/item?id=2515796>

for a FAQ on the distinction between problems and exercises in mathematics education.

<comment><USER6> I side much more Conrad Wolfram on this than Stillwell [1]. Computation simply is a lot less important now as we have tools that do them with far greater speed and accuracy. And I'm from the generation that did tons of computation, but I honestly never had a great grasp of it. I just knew there were steps to be taken (leave an extra space to right as you do long multiplication) -- and I was one of the top math students in the district.

In fact I'd argue that I never really understood much of any math until grad school. I was computational sophisticated, but lacked understanding.

And oddly, I seem to find quite the opposite problem from what the blog author describes. I find students who know 3x5. But struggle to understand when the Fourier Transform is appropriate. Sure, if they're looking at problem sets at the back of the chapter about Fourier Transforms then they'll start with it, but in the real world they lack the conceptual understanding of it. I've met students who can compute the SVD, they can tell you the text book definition, but don't actually intuitively know what it means. They don't know when it should be applied, or when it is applied, what it means.

[1] [http://blog.wolfram.com/2010/11/23/conrad-wolframs-ted- talk-...](http://blog.wolfram.com/2010/11/23/conrad-wolframs-ted-talk-stop- teaching-calculating-start-teaching-math/)

<comment><USER35> As a student in a fairly good university(Umass), Math tends to be taught exactly how you describe it. "Heres the FT. This is where you use it. This is how you do it". Most students will be able to do the FT, and most students can actually find the correct answer. However, because teachers and books tend to formulate very artificial situations where the a specific tool students often are used to looking for very specific patterns inside problems to decide what tool they will use for the job. When a problem falls outside the usual patterns, students will have a hard time identifying the tool they should use.

I see this all the time when I help someone with a programming assignment. They may understand the problem, they may understand each individual solution if you explain it to them. However, they usually do not know where they should start. They may understand what a hash table is, and they may even know how to implement one. However if a problem does not fall into one of the patterns they are used to for a "hash table problem" they may not realize right away that they could use such a solution.

Kids need to be taught how to break down a problem into its elements, and then realize which elements can be solved most effectively by what tool. This can also be learned through experience. Program enough and you will eventually start to break down problems yourself. But some kids don't seem to take initiative and work on themselves outside school. Which also is the reason why some kids from Umass CS are working at Facebook, Google, Microsoft, and others serve me coffee.

</comment></comment></comment><comment><USER36> I saw nothing about mathematics here; this was all about arithmetic.

</comment><comment><USER37> The best way to teach mathematics is to put it in a useful context. Want to teach trig? Have students build a set of stairs. When students need it to solve a problem they will figure it out and intuitively understand it. The primary problem with mathematics teaching and education in general is that students know the knowledge but have no idea how to apply it.

I didn't learn to program by sitting in a class having someone drone on, I learned it because I needed it to solve problems I had.

</comment><comment><USER38> "I plan to remain hard-headed about this until I am convinced that abandoning the rote sorts of exercises done in, say, a linear algebra class (which can also be done on a calculator) does not hinder our ability to form intuition about how to do proofs, etc"

It is positive statements that require proof, not negative ones. If you believe that the introduction of calculators, google maps, etc., has negatively impacted number sense and human spacial reasoning, it is on you to prove it.

</comment><comment><USER39> what i gained from learnign math using trig and log tables, pencil and paper to calculate fractions, multiplying them, more numbers, more calculations, => feel for a solution. yes, it is subjective, by looking at a problem there are no magic that pops out, just a feel for what would be a correct answer. objectively, the experience how to simplify is a great gain as well. ... then i studied logics. today i can calcualte areas, circumferences in my head, faster then using my phones calculator. the precesion is acceptable for my daily use.

</comment><comment><USER28> The worst part is, how old is all this stuff, and how was it able to be passed along for generations until now?

</comment><comment><USER40> I read years ago that taking notes about everything diminished our capacity to memorize things. Now I can't remember where I left my notepad ;) (But seriously, exercizing our natural gift of thought is essential for good brain shape.)

</comment><comment><USER41> Just count in binary, everything will be easier.

110 * 111 = 101010

Very easy, don't you think? :)

</comment><comment><USER42> This might be true for any other field than math, but the basic understanding of math you need today is no different from what Pythagoras and Euclid needed.

<comment><USER5> You're arguing against basic mathematical education on the basis of not being needed to a country with the highest personal debt levels the world has ever seen.

<comment><USER43> To me, US personal debt seems like more of a self control issue than a problem of innumeracy.

<comment><USER5> Self control however is much better maintained with a proper understanding of the problem.

This is why payday loan sharks target poor areas: lack of education.</comment></comment></comment></comment>


Congress Gives Commercial Drones Takeoff Clearance for 2015 - <AUTHOR> http://siliconfilter.com/congress-gives-commercial-drones-takeoff-clearance-for-2015/

<comment><USER2> Here's hoping FedEx or UPS are the first buyers of commercial drones. Same day shipping from anywhere won't be far around the corner.</comment>


Ask HN: How much money do you make every month from your iOS app? - <AUTHOR>

<comment><USER2> My buddy and I make between $50,000 - $60,000 per month. We have been doing this exactly 1 year.

<comment><USER3> Good for you! That is like 6MM a year! Pretty soon you can retire!

Do you get most of your revenue from Ads, paid apps or In App Purchase?

<comment><USER4> Your math is off by an order of magnitude, but 50k a month is still amazing.

<comment><USER3> Oops...LOL ... I got too excited!

</comment></comment></comment></comment><comment><USER5> Was making between $500-$900/month consistently for 1+ year, but the release of iOS6 hit my download count significantly. The app is Group Texting Pro

</comment><comment><USER6> I make about $100 - $200 as a hobby developer of one paid app. It has been in the store about 4 years. App is Geometry Stash.

</comment><comment><USER7> About $200-400 a month on one paid iPad app in the Music category</comment>


Hate Java? Maybe you should hate the industries stuck in the 50's. - <AUTHOR> http://blog.jelastic.com/2012/08/13/hate-java/ <comment><USER2> I always had the impression that people that say they 'hate Java', usually don't hate "Java: the language". Most people that dislike programming in Java have a negative sentiment because of:

\- the usage of XML (or now: annotations) to configure all of the tiny parameters that nobody really cares about

\- a class hierarchy in which you have to jump to 20 levels of inheritance to get to where you want to go

\- that a lot of Java developers aren't able to compile their application outside of Eclipse

\- that people build in "flexibility" in form of factory methods but at the same time only have the factory only build the same thing over and over again

\- that setting up java projects is usually an unpleasant experience with way to much work if you only want the basic functionality because there are no sane defaults

\- that there is no proper package management for libraries (similar to something like 'gems' in Ruby)

\- that all of the concepts that the language is missing was 'patched' in using reflection, injection and annotations

\- that the language just seems stuck (for how long did the Java community talk about Lambdas by now?)

\- that most Java libraries don't seem to be able to provide a simple example (compare to ruby, examples on the front page: nokogiri.org, sinatrarb.com)

<comment><USER3> I agree with all of this -- Maven has fixed the issue with package management to _some_ extent.

<comment><USER2> Using maven was a horrible experience for me every single time :(

It seemed to download the whole internet and POM files are using everybody's favorite configuration language: XML

<comment><USER4> It is, but it uses XML _right_ : for a declarative document, and one that has tools for editing rather than having to do it by hand. Maven is glorious because it ensures your builds are actually reproducible, something which I've never seen any other language or build tool accomplish.

<comment><USER5> What a non-sense. You can't sanely describe build of your project(s) in documents. Did Maven folks include every possible scenario in markup? Nope. And that's why all Maven builds that are not simple jar of classes tends to have long sequentional calls of build plugins.

I see it this way:

First we had bash and make and ability to do almost everything (run other programs, ...) by using the right thing/language for the job. There was only lack of the functions to deal with Java builds and package management.

Then we had Ant, XML programming language with very limited possibilites (I don't regard targets as a feature). But at least we could express what we wanted.

Then we had Maven. If we needed something special we need to add it to sequence of build plugins (in several hardcoded build phases). Mostly we resort to do things in Ant plugin.

This is why I hate Java. Because of such idiocy.

<comment><USER4> The ability to call random external programs during the build of your project is not a feature, it's a bug. Likewise the ability to lay out your source arbitrarily. Your project's build is not a unique and special snowflake; it can build the same way as every other project, the way that has already been tried and tested by millions, the way that any developer will immediately understand.

If there's really some step that needs to be done in your builds that isn't covered by the existing plugins, you can write your own (it's not hard) and then at least that step is happening in a structured, testable way. But if you're doing something unique to a single project, you shouldn't be doing it in the build system.

<comment><USER6> > Your project's build is not a unique and special snowflake; it can build the > same way as every other project, the way that has already been tried and > tested by millions, the way that any developer will immediately understand.

No, actually, builds can get very unique in multi-language systems or in embedded systems... believe me. =)

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I've recently come back to java after around 5-ish years doing mostly ruby. Know what? It's been a breath of fresh air. Code performs as you'd expect, and when you need to track down behavior, it's usually very straightforward (completely the opposite of ruby, in my experience). Almost _everything_ runs super-fast. IDE's actually work with it. Docs are very good.

When I hanker for dynamicity, I've been reaching for groovy...a language I tried years ago which has come a LONG way and brings a lot of the features (namely, anonymous blocks/closures) I liked about Ruby. I'm nervously courting scala but in the early days.

What I liked about Rails can for the most part be found in Play (<http://www.playframework.org>), although I must admit I felt better about Play in its 1.x days when it was written in java. The core is now written in scala (though _you_ can develop your app in either java or scala)...perhaps as I learn more of this language I'll feel more comfortable opening Play 2's hood. We're already started converting one of our Rails applications to Play, and it's been a great experience so far. And oh, by the way, we're finding that whole "rails/ruby won't slow you down...your database will slow you down" argument isn't always true.

Anyway, count me among Java's (and the jvm's) fans. It probably doesn't hurt that I have been working with it in one way or another since 2001, but I tried my best to leave it, only to find that sometimes you can indeed go home again.

<comment><USER7> That said, it hurts my brain to understand why in 2012 we're still forced to create our own empty getters and setters, and why there are no anonymous blocks. I know that closures/anonymous blocks are supposed to be delivered in java 8, but I'm not sure the elimination of redundant getters/setters are even on the road map. I'm so tired of opening classes which are comprised of 20% business logic and 80% getters/setters simply because one might need to override that behavior in the future. It really increases the noise.

<comment><USER8> Have you considered using Project Lombok? <http://projectlombok.org/>

<comment><USER7> I have. Little too magic for me.

</comment></comment></comment></comment><comment><USER9> Wow, what a chip on this guy's shoulder. If you're a single-language Java (or Cobol) programmer don't worry, your career is safe. But don't write rants telling other programmers what they should care about. There is absolutely zero chance I am going to give a shit about antiquated IT and business processes not being updated. Management has their reasons, and I have no interest in fighting to convince them otherwise. Rather I will work at a company that is doing interesting things with tools that I like.

I don't dislike Java out of popularity, I just don't find it to be a pleasant or expressive language. I like to code in vim without an IDE, so a lot of verbosity and boilerplate is painful. If I want static typing, I prefer a much more expressive and powerful language like Haskell, because frankly I just don't see what the point of static typing is if I'm going to get null pointer exceptions all over the place.

</comment><comment><USER10> I don't get why people complain so much about Java. It's definitely not perfect, but it's not a complicate language to use. People complain that it is slow; well it's much faster than dynamic languages. People complain that it is verbose. Yeah, maybe more compared to dynamically typed languages. But personnaly, I don't have much of an issue with Java. It's not hard to read, not hard to write, and to my experience, its runtime behavior is easy to predict.

When I look at benchmarks of languages (notably this [1]), and compare Java to say Ruby or Python, it's about 40 times faster, and compare pretty well versus C++. And I'd rather code something in Java than in C++ everyday, all the time.

Now I'm not versed in the benchmarking of languages, and I don't care that much about them as I understand that they are not very reliable. But when I need a lil'more performance than Python or Ruby, but that I don't want to ruin my psychological balance with C++, I'm quite happy to have Java.

Maybe it's just my lack of knowledge that gets me to have this opinion. Maybe once I get a chance to try out Go and Scala, I'll find there is no reason to use Java anymore. But I don't think I'll get to the opinion that is it terrible and that it deserves to be hated and laughed at.

[1] [http://shootout.alioth.debian.org/u32/which-programming- lang...](http://shootout.alioth.debian.org/u32/which-programming-languages- are-fastest.php)

[Edit1] weakly -> dynamically

<comment><USER11> Try out Scala. It's a superior substitute for Java in every possible way.

And even if my last statement is hyperbole, you can still use Java in your scala project for the critical parts where scala doesn't do a good enough job. Sbt, the standard scala build tool typically builds you src/main/scala and src/main/java folders. Write scala in the scala folders, java in the java folders, they can easily refer to each other, it's all seamless.

<comment><USER12> Only problem is the scala community is teeny tiny, tool support isn't there (There isn't an IDE with a scala plugin that fully supports scala), pure scala libraries tend to be unreadable and lack any solid documentation (looking at you scalaz, lift, and dispatch), and I think most importantly the scala compiler is SLOW.

I've written a bunch of production Scala code, and I'm glad to have gotten away from it. Obviously to each their own.

<comment><USER13> _There isn't an IDE with a scala plugin that fully supports scala_

IntelliJ provides an excellent free scala plugin. What have you been using?

<comment><USER12> I mainly used the Intellij scala plugin... It's code completion was incomplete and it identified syntax and type errors that weren't errors. This was on the latest intellij with the latest plugin.

<comment><USER13> Yeah that seems to happen if you leave type aware highlighting enabled. Seems to work well with that switched off.

</comment></comment></comment></comment></comment></comment><comment><USER3> This article is a troll, but I'll bite: I'm not going to justify all of these, but this is my short list:

1) Java is slow (the JIT hides only some of this -- see below)

2) Java makes working in Hashes and arrays very painful

3) Very little functional support (yes, Java8 will help)

4) The java language moves forward very, very, very slowly

5) It scalability is a joke. I've worked as a Java contractor at a number of places and what a PERL/PHP/Python solution can get done in 5 boxes, it takes Java 30-40 boxes. This is _NOT_ an exagerration. I think it's a side effect of some developers stuffing everything into the session and expecting clustering to fix everything.

6) Date and file handling is also really painful. (yes, JODA helps, but we're 15+ years into Java and only finally getting good date support baked into the language)

7) Library management. Maven has largely "fixed" this issue at last, but sorting through library conflicts in order to write in an exception is still not fun. And as already noted, this is one of the reasons you can't just jump in with a text editor and hammer out a simple example.

The library support of Java makes up for a lot, but honestly, Python looks better and better every day.

edit: I will add in support for why many, including myself perceive java to be slow. The startup of the JVM is horrendous. If you're doing even moderate web development, there is a _minimum_ two to three second startup period for a web server. That simply doesn't exist in PERL/PHP/Python. There's no such thing as a permgen error in PERL/PHP/Python. I've never seen PERL/PHP/Python go off and spin the disk as furiously as Java trying to load classes. It's ridiculous.

Java's strength is its maintainability and library support.

<comment><USER7> _5) It scalability is a joke. I've worked as a Java contractor at a number of places and what a PERL/PHP/Python solution can get done in 5 boxes, it takes Java 30-40 boxes. This is NOT an exagerration. I think it's a side effect of some developers stuffing everything into the session and expecting clustering to fix everything._

Umm...I think you've been working in the wrong Java shops. I've never seen, nor do I believe it's possible, for a well-written python/perl/php app to be faster than a well-written Java app.

 _The startup of the JVM is horrendous. If you're doing even moderate web development, there is a minimum two to three second startup period for a web server. That simply doesn't exist in PERL/PHP/Python. There's no such thing as a permgen error in PERL/PHP/Python. I've never seen PERL/PHP/Python go off and spin the disk as furiously as Java trying to load classes. It's ridiculous._

Sure, Java's start-up is slow. But it shouldn't be an issue in web apps since your application will likely use threads if it's a Java app. I can see if your app was process-oriented, like many ruby/python web apps are, but with Java's native thread support it makes no sense to start up multiple processes unless you really have a need for the separation.

<comment><USER3> _> Umm...I think you've been working in the wrong Java shops. I've never seen, nor do I believe it's possible, for a well-written python/perl/php app to be faster than a well-written Java app. _

I've been in the industry over 20 years. I've seen plenty. It is easy to assume that the java and a JIT should be able to take advantage of all the extra information to make fast code. But in practice, when you add in all the frameworks and abstraction overhead, Java on the web is slower. I _routinely_ hit stack traces well over 50 levels of depth. Benchmarks really don't take this into account.

> _Sure, Java's start-up is slow. But it shouldn't be an issue in web apps > since your application will likely use threads if it's a Java app. I can see > if your app was process-oriented, like many ruby/python web apps are, but > with Java's native thread support it makes no sense to start up multiple > processes unless you really have a need for the separation._

I mostly agree with what you say. It is mostly a development issue. While most software development in Java attempts to be centered around TDD and therefore eliminate the whole start-restart cycle, the ugly truth is that there are reasons that tools like JRebel exist.

<comment><USER7> _> I've been in the industry over 20 years. I've seen plenty. It is easy to assume that the java and a JIT should be able to take advantage of all the extra information to make fast code. But in practice, when you add in all the frameworks and abstraction overhead, Java on the web is slower. I routinely hit stack traces well over 50 levels of depth. Benchmarks really don't take this into account._

But your original post said Java was slow. It's not. Don't conflate the language with bad frameworks written with it.

</comment></comment></comment></comment><comment><USER14> I don't hate the Java language. I hate the Java ecosystem.

The teams I work with that use Java end up being the slowest moving teams because they can't deploy even the simplest code changes without a lot of pomp and circumstance and inability to upgrade their servers without disrupting the whole fragile of chain version dependencies. The java teams are the only teams that have to stop the world for hours when doing server code upgrades. Rails and PHP teams have much simple code deployments.

<comment><USER15> They should pick a better ecosystem then. With Maven and Jenkins I simply tag a release in git and Jenkins automatically builds new war files that are deployable by copying them to a deploy/ directory. This basically means:

git tag -a v1.0.1 -m 'Version 1.0.1' ... wait till build is done ... cd $WEB_SERVER_HOME/deploy curl -O <http://repo/myapp-1.0.1.war>

Done. The last step can also be automated. I've worked with setups where production machines simply follow tagged release builds. Or just use puppet.

Java can rock. Specially with Maven it takes away so much pain of build/package/deploy.

</comment></comment><comment><USER16> So, kind of playing devil's advocate here, but what do paying with a credit card, adjusting your 401K, using an insurance card at the dentist, shopping for the best car insurance and transferring money between banks have in common? People can lose money if the system fails or is simply not reliable. What do going to the emergency room, a BNSF train pulling a Union Pacific coal car and filling a prescription have in common? People can die if the system fails or is simply not reliable.

These industries and the activities listed have an inherent level of risk associated with them. The existing systems work well enough that we take the safety of these activities for granted. So while as an engineer, I might hate working with old, outdated technology and not want to work in these industries, as a consumer I appreciate that the people governing these industries are perhaps overly cautious.

</comment><comment><USER17> Arguing about problem #1 doesn't mean it takes away effort from dealing with problem #2. Maybe the author should also write a blog post about "How can you waste time arguing about eating your vegetables while THERE ARE COBOL LINES?"

Is that the most important problem for the tech industry? For the human race? If the proverbial twitter DSL programmer wouldn't proverbially create a DSL, would he use that time to meaningfully solve the systems' antiquity problem in the X sector? Even if so, is that the most important/bang-to-buck problem in known existence?

</comment><comment><USER18> I find it ironic that many of the arguments implied for "COBOL is absurd" can be turned to make the case that "Java is absurd." Both have a legacy of accumulated complexity, and some programmers dislike the buden this creates. Others are genuinely concerned that Oracle is positioning itself to profit from the accumulated legacy in the same way the author complains that mainframe vendors have done. The community of people that tends to develop around a language matters immensely in shaping the character of the code that inevitably accumulates.

Java has a history of conservative implementation choices (E.g., see Guy Steele's account of some of those choices at [1]) Having lived through both, the Java world of a dozen years ago reminded me so much of the COBOL world of the 80's, I personally chose to move on to more innovative communities. I still occassionaly write Java, and am always struck by how memory-intensive it is and by how it always seems to abstract by spreading things out rather than by compression.

Regardless of your own preferences and choices, my recommendation to younger programmers would be to work hard to avoid getting stuck in any language rut. If you think of yourself as a "Java programmer," then you might already be a casualty of your circumstances.

[1] <http://article.gmane.org/gmane.comp.lang.lightweight/2274>

</comment><comment><USER19> As a user but nonprogrammer of java I have never found java to be cross- platform. It seems every application of any real complexity has required me to go on an hour long hunt for the right version and dependencies. If it take me longer to make your "cross-platform" application cross-platform than it does to install an OS, then there is a problem. These days if I get a whiff that a project is java based I avoid it and keep looking for another solution.

</comment><comment><USER20> Oh, the irony of advocating peace and love for java whilst waging a war against COBOL.

How about we confine language battles to language specific discussions (and I don't see anything wrong with those) and concentrate the overall engineering argument on getting good practice in every language. I can get behind the sentiment of replacing legacy systems but I don't see the point in hating on COBOL.

<comment><USER21> I think you missed the point. I think the point is about not having religious wars over languages for ideological reasons but instead focus on the practical cost and benefit of the languages. He pointed out the people running the COBOL mainframes were paying ridiculous licensing fees for their databases.

</comment></comment><comment><USER22> I used to work in the insurance systems industry. There are many, many expensive problems that have to be solved before legacy systems can be replaced. In no particular order:

* The Myth of Uniqueness: Each and every company doing business believes that their business is different and couldn't possibly be the same as another company's. This is not completely untrue, but it's also not completely true. The problem is that this myth is propagated by the enterprise software vendors. The profit margins on services to customize software is far, far greater than the margins on software licenses. It is in vendors best interest to promote software customization.

* 50 Years of Customization is Hard to Throw Away: OK, maybe there's not many 50 year old systems running in production any more, but there are 25 year old systems. The amount of money spent to customize those systems over the years is enormous and big corps are not eager to toss that money spent away to start over.

* Database Conversion is Hard: Not so much difficult, but hard in the sense that it requires many, many hours to first clean up the old database, run the conversion, then validate the new data. One mistake could mean that someone's policy lapses because the conversion broke the automated Pre-Authorized Cheque processing code for that one client.

* Working at Big Corps is Uncool: Let's face it, being a programmer at a big bank or insurance company is perceived as boring. The over 40 set that these jobs appeal to aren't traditionally big adopters of new technology. As these people get promoted into decision making roles, they default to safe, known technologies.

* Corporate Partnerships: Big financial industry companies outsource their IT to corporations like IBM. These services companies have a vested interest in maintaining the status quo. It's much like bee-keeping bears ;)

* The old stuff still works: Even though the legacy code is unreadable and numbers in the millions of lines, it still mostly works. The "if it ain't broke, don't fix it" argument is an easy one to make when your executives (beholden to the shareholders) have to make their quarterly numbers.

Don't get me wrong, I'd love to see start-ups in the financial services software industry pop up with innovative solutions. In fact, I've thought about attempting this myself, given my background. But the elephant herd of legacy vendors to find your way around is extremely intimidating. In fact, I actually saw a few small vendors pop up over the years, get small contracts within the big insurance company to do something innovative with their shiny new technology (but not mission critical to the corporation), and then watch that company take on more and more lucrative services contracts further from their core software product. Eventually, their initial product offering becomes a footnote for them and they turn into something else, legacy related.

<comment><USER23> Everything you so aptly described also applies to the healthcare industry, which is mired in a language from the 60s (MUMPS).

<comment><USER24> Here in Finland (population 5 million) the government is preparing to allocate ca. 1500 million euros to order a country-wide medical patient database from Accenture, who are the local representative for Epic Systems [1] and Epic's MUMPS-based [2] medical information systems.

[1] <http://en.wikipedia.org/wiki/Epic_Systems>

[2] <http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx>

<comment><USER25> My apologies. I live in the area where Epic is based. They tend to hire straight out of college and work their employees into the ground. It's a weird subculture over there, but they're swimming in money for all the government kickbacks hospitals get for implementing electronic medical records here in the States. [http://www.cms.gov/Regulations-and- Guidance/Legislation/EHRI...](http://www.cms.gov/Regulations-and- Guidance/Legislation/EHRIncentivePrograms/index.html?redirect=/EHRIncentivePrograms/)

</comment></comment></comment></comment><comment><USER26> I found this statement particularly surprising:

>Java, with its faults, has completely conquered web >application programming.

Is there any evidence that this is true? It's certainly my experience that the direct opposite is true. Java is traditionally considered successful in everything _except_ web application development.

<comment><USER27> The statement is certainly correct for webapps of a certain scale, meaning enterprise-scale, not startups. I'm not sure where you get the idea that Java is successful in anything else - certainly not in desktop apps, games, embedded (except for Android), etc.

</comment></comment><comment><USER28> Java is a tad boring to program in, but other than that there's not too much to complain about. I'm personally going to stick to what I think is its best part, the JVM, and use Clojure to abstract myself from all the lower level necessities.

At this point for me Clojure is simply more fun to write in, although it remains to be seen if it gets ever accepted into the "industry best practices" mainstream that will make your boss sleep well at night, just like Java has for the past decade. Some of the old school LISPers (I'm talking people 70 and older who taught the language before I was even born) I know claim that they haven't gotten bored yet, so there's hope.

</comment><comment><USER29> While the OP is correct about how arcane these industries are, there's one statement I just couldn't agree with:

> So, why suddenly, in late 2010 and 2011, is Java suddenly the hated demon it > is?

Suddenly? In the 2010s? Hah! I hated Java practically since _the turn of the century_ , and only in the last 2 years did I relax and admit that it's become a good language/environment. But with Oracle's acquisition I don't see that staying. It was because of how Sun ran Java that the language flourished—if Oracle so much as sneezes, or even insinuates a change in policy, the language could see a major shift.

</comment><comment><USER30> We don't hate Java. We hate the developers who create ugly code in Java.

</comment><comment><USER31> Posted at the article, but the blog is censored ("Comment is awaiting moderation").

On a high level, Java vs Ruby/Python is a question of suitability to purpose.

Java is a great language for large teams of incompetent programmers. You will not be able to find competent programmers to code up the business logic for: Paying with a credit card. Going to the emergency room. Adjusting your 401k. Using your insurance card at the dentist. Filling a prescription.

That code is mindnumbingly boring, and has few technical challenges beyond sheer size and complexity.

With incompetent programmers, you want a B&D language -- Java forces object oriented. It forces a single object oriented paradigm. It forces a set of standard libraries. Etc. It makes it as hard as possible for programmers to shoot themselves in the foot, and it minimizes learning curve to get up to speed, making programmers as interchangeable as possible. If you've got a team of half-wits trying to write an employee management system, that's exactly what you want. The problem falls well within the limitations of the system. If you want to do something more complex -- a startup solving a problem that's never been solved before -- and you have a team of hotshot programmers, you really do want a less constricting and more flexible language.

COBOL is obsolete. Java vs. Python/Ruby vs. LISP/Scheme is a question of suitability to purpose -- primarily problem difficulty and team composition.

<comment><USER32> > Posted at the article, but the blog is censored ("Comment is awaiting > moderation").

That's not censorship. That's the default setting for Wordpress blogs.

<comment><AUTHOR> Didn't see any comment, unless you put it on Jonathan's blog.

<comment><USER32> Well, like I said, Wordpress defaults to placing all comments from new commenters in moderation.

It's a flawless test for internet tinfoilery; such people immediately allege scandalous CENSORSHIP when the software mindlessly does what it always does.

</comment></comment></comment></comment><comment><USER33> I use Java in my day job and it's easy enough to write code in.

The problem with it for me is, it's totally unusable for writing quick command line scripts/applications because you need to either

a) Run java -cp <classpath> <class-with-main>

b) Write a shell/batch script to do the above.

Then there's the lack of good stuff found in modern languages like first class functions.

It's not all bad though, recently I've been learning Go and the lack of generics makes me pine again for Java like a long lost love.

<comment><USER34> Really? requiring a shell alias or a one line shell script to shorten your invocation makes the entire language 'totally unusable'?

<comment><AUTHOR> You kinda have to agree that writing anything in Java isn't exactly... "fast". That said, I don't use Java for "quick answers" -- if I want something that super easy and needed tomorrow, I'll do it in Ruby (especially if I know that it's not going to need to scale massively or get tons a hits and requests).

</comment></comment></comment><comment><USER35> The reason I dislike Java is because the barrier to entry is so high for beginners.

      public class HelloWorld {
          public static void main(String[] args) {
              System.out.println("Hello, World");
          }
      }

First, you need to wrestle with Eclipse. Then you need to figure out things like class and void and static and public before you can event print something to the screen. Ugh. So...much...syntax.

<comment><USER13> High school students all over the world are quite happy to write Java code like that without any issues.

<comment><USER36> No they aren't. It's appalling to me that high schools actually use Java for introducing a subject that requires immersion to be successful. Nobody sees "Hello World" or any other intro app in Java and thinks to themselves, "Hey, wouldn't it be awesome if I spent hours on end making this compiler thingy happy." If students aren't actually making things they can use and play with, you're going to find very little adoption outside of the school-mandated time it takes to pass the next test. This is why Javascript, Ruby, Python, hell, even VB are so important.

1) Make them want to write code 2) Show them how to reason about the code (this is where CS classes should come in)

<comment><USER13> If it took you hours to get hello world working perhaps you should consider going back to school?

</comment></comment></comment></comment><comment><USER37> This response is less on Java and more on the author's opinion of mainframes.

Large companies are risk adverse and generally for a good reason. That mainframe running COBOL has probably been reliably processing orders, crunching financials, and managing inventory for 30 years. No one is going to replace that on a whim because COBOL isn't cool. What are they going to use instead? It's certainly not Mongo DB and Lua scripts on AWS. SAP possibly, but you still end up with an expensive system with even more unpredictable cost and licensing terms.

</comment><comment><USER38> Java is a fine tool for many applications. And like it or not, it is going to be around for a long time.

The problem I see with Java is that we're not sure whether Oracle is taking good care of it.

</comment><comment><USER39> There are several myths perpetuated by Java. Perhaps you can simply call them "biases". It's certainly not the most modern language but like most things, it's what you make of it. Here's my rebuttal to a few:

1\. People equate Java IDEs with Eclipse and all it's problems. This one drives me the most nuts. IntelliJ is like night and day compared to Eclipse. I honestly don't understand why anyone uses Eclipse.

For years I've listened to Eclipse apologists for things like:

\- Maven integration doesn't work. You need to add custom directives for m2eclipse (in IJ, you just open a pom.xml and you're _done_ );

\- Previously, there were two Subversion plugins for Eclipse and neither of them worked entirely right. VCS integration in IJ is excellent;

\- Find and Replace across files is awkward and slow in Eclipse. It's fast and efficient in IJ;

\- At Google, it's a running joke about Eclipse grey-screening (with our custom build processes and dependencies and so forth) to the point where it's been described as "turn-based programming". We can use IJ too and it has good Google integration but less resources dedicated to it. Still I've found it generally far less problematic;

\- Am immense list of subtle improvements over Eclipse. Even something as simple as scope selection. Keep pressing ctrl+W in IJ you select the parameter, then all parameters, then the function call, then the block, etc. There is a similar(ish) command in Eclipse you can bind to a key but it's just not as good. That's just one example;

2\. Java means using bloated frameworks like JSF, EJB2, etc. It does not. For example, I'm currently using Spring MVC (I haven't found a good relatively lightweight Guice-based Web framework yet) and Objectify on AppEngine;

3\. You can't do closures in Java. You can. It's just incredibly verbose. Guava [1] is pervasive in Google. I highly recommend it. So you can write:

        List<String> uppercase = Lists.transform(inputStrings, new Function<String, String>() {
          @Override
          public String apply(String input) {
            return input.toUpperCase();
          }
        });

Granted it's much terser in, say, Python:

        uppercase = map(lambda x: x.upper(), input)

or (my personal preference):

        uppercase = [x.upper() for x in input]

But more on this in (4)...

4\. There is a lot of boilerplate in Java. There is and there isn't. Empirically there is but it doesn't matter. Take the above function. I type (in IJ):

        List<String> uppercase = Lists.tr (autocomplete "ansform(") new (ctrl+space fills in the entire Function<> definition with correct types)

Same for getters and setters. I press alt+insert, getters and setters and select the ones that have them. You can also auto-fill equals, hashCode and toString methods (although the Guava versions of those don't seem to have a generator).

5\. Java means using checked exceptions. While I also loathe checked exceptions, this simply isn't true. It's one reason I like Spring. It tends to wrap most checked exceptions in unchecked ones (eg DataAccessExceptions instead of SQLExceptions).

6\. IMHO Maven is great. Previously there was Ant and of course everyone thought their installation was different or they had their own preferences about where files should be. I like that Maven is "opinionated". It means you can go to any Maven Web project and know where to find things. YMMV.

Anyway, back to the issue at hand...

I've spent years working in such companies. It does tend to be a quagmire of mediocrity and politics but not always. We, as engineers, tend to forget that the easiest way to get anything done in such a company is to make a business case for added productivity, cost savings, risk management or whatever. Once you master this trick you can pretty much do whatever you want. It's simply the language the higher ups tend to speak.

Also, people don't tend to give enough credit to just how hard some of these jobs can be. Business processes and data migrations are incredibly tedious and they need to work.

Also, no matter how bad systems might be engineers tend to underestimate the ability of people to make them work. As engineers we tend to want to automate people out of pretty much everything we can. Often having some person look at something or correct something is far easier, cheaper and less risky than any automated solution or systems change.

[1]: <http://code.google.com/p/guava-libraries/>

<comment><USER4> 1\. IntelliJ forces you to manually build your project. This is enough to force me to use eclipse despite all its problems

2\. Sure, you don't have to use the frameworks, but they're one of Java's big selling points. If you didn't want them why would you use java?

3\. I think you make the point for me. Sure, closures aren't impossible in Java, they're just much harder than they should be.

4\. Boilerplate isn't just there when you write it, it's there when you read the code, which is much more important. The one major live bug I introduced was when I accidentally replaced a getter that had some code in with an autogenerated one.

5\. It is true in that there are a bunch of standard library methods that throw checked exceptions (e.g. file I/O), so like them or not you have to handle them.

<comment><USER40> Why should continual/incremental compilation be part of the IDE?

You can do this in a separate process, the IDE only needs to detect that some .class files have changed and refresh the metadata of those files.

Eclipse support for this is sure nice, but then I hate Eclipse for being bloated, with a sluggish interface and shoehorning such features on top is the reason why Eclipse is the way it is.

<comment><USER4> The IDE is supposed to be integrated, and compilation is one of its main responsibilities. I don't really care how it's accomplished, but I can't write java without "new errors show up in my IDE whenever I hit save". If there's an easy way to set up this separate process malarky then I'm interested.

</comment></comment></comment></comment><comment><USER40>
         Java ... It's one of the fastest languages

Languages aren't inherently fast or slow, that's rather the quality of the underlying virtual machine / hardware architecture the compiled binaries run on. I think everybody can remember the days before Java 1.4 where the official JVM sucked performance wise. Did that mean Java the language is slow?

Of course, in designing a programming language, the architect can make some tradeoffs that will make the resulting implementations of certain algorithms run faster or consume less memory. So on one hand the architect can make tradeoffs regarding some features of the language that may help with performance, but on the other hand those tradeoffs can also stay in your way when trying to do higher-level optimizations.

         Community governance via that JCP (pre-Oracle).

It was Sun that refused to give a license for the TCK to Apache Harmony. The JCP was never nothing more than a bunch of people and companies bending over to Sun, now Oracle.

Of course, because of OpenJDK and because Sun always projected this "open" image of Java to the world, the genie is out of the bottle because OpenJDK can be forked, and because APIs aren't copyrightable (although that's still a gray area), so even third party implementations are possible (as seen in the Google vs Oracle trial). So Oracle has to be a good citizen here, or else they risk losing whatever control they have left.

But the JCP was never and probably will never be a standards body and Java will never be a published standard, in the same sense that C/C++ are.

         It's popular to hate Java

You should definitely have feelings for programming languages, but only immature people think in terms of love/hate based on what other people think (basically you're kind of incompetent or still wet behind the ears if you hate Java based on what other people say about it).

Many of us in the trenches avoid using Java because it's lower-level than say, Ruby, or Clojure, or Scala. But Java is still there, still kicking ass, whenever the high-level abstractions are in our way, or whenever we are part of something bigger that imposes Java on us (like company politics). The same can be said about C/C++ - still kicking ass, but you don't really have to go that low level for 99% of the times, unless the project or organization dictates it. So why should you? Best tool for the job, right?

         ... are the industries that
         are still stuck in the 50′s the problem?

Because you know, we should rewrite everything from scratch every 5 years or so.

<comment><USER41> "Languages aren't inherently fast or slow, that's rather the quality of the underlying virtual machine / hardware architecture the compiled binaries run on."

That's not really true. Some language semantics and features are difficult to implement in an efficient manner. Continuations are a good example. Dynamic typing, also can be inefficient because of the need for runtime inspection of object metadata. Clojure has this problem and that's why they added type- hints, purely as a speed hack to avoid this problem. True, most of Java's speed is probably due to the Hotspot VM, but in practice, it's still among the faster languages out there, certainly among the garbage collected languages.

<comment><USER40> That statement I made is definitely true.

I'm not arguing for or against Java, I'm arguing that both the hypothesis and the conclusion and everything about that article is flawed (it basically screams LINK-BAIT).

         Continuations are a good example

First of all, most implementations for continuations that are in common use are on top of virtual machines that are stack-based, so providing first-class continuations is a bitch, because you've got no way out of it other than to save the classical call-stack somewhere and restore it later, should you need to. And because of the way the call-stack is implemented, saving / restoring it is both time and space consuming.

This was a pragmatic decision, more often than not, because explicit support is really not that useful, while being error-prone and because the major use- cases, like exceptions handling, coroutines, asynchronous tasks, etc... can receive language support that's also optimal on top of a stack-based VMs. And in most cases you don't need the unlimited extent that continuations on top of Scheme provide (most people just need the "async" support like it was done in C#, which is just compiler-related syntactic sugar). Some people even consider continuations "harmful" as sort of a modern Goto (a topic on which I have no opinion btw).

However, if you get rid of the traditional call-stack and make all methods receive an implicit continuation of the caller, and overload the "return" operator to call that implicit continuation (basically making _everything_ CPS), then you could optimize this more efficiently. By how much, nobody knows yet, because there have been only weak attempts at solving this (I only know of Parrot, the new Perl 6 VM, but it hasn't done anything spectacular yet).

Also remember that our current commodity, general-purpose hardware is optimized primarily for C, which assumes a traditional call-stack. And you can always design hardware that's optimized for different things.

         Dynamic typing ... Clojure has this problem and that's
         why they added type-hints

You haven't actually mentioned the exact problem Clojure is having. Clojure added type-hints mostly to avoid primitive boxing/unboxing. It doesn't have much to do with "dynamic typing".

In case you weren't aware, the JVM bytecode is pretty dynamic. Besides primitive operations on primitives, which have special bytecode instructions, the only place where you really, really need the name of a class or interface is when calling a method. And so the name of the Class.method ends up hardcoded in the bytecode, but that's only because Java itself has clear rules for method-lookup, so providing the means to override that method-lookup was unnecessary.

However in Java 7 they added invoke_dynamic, which does provide the means of overriding the method-lookup being done. JVM engineers, like John Rose, promised the same performance characteristics as invoke_virtual.

But Clojure doesn't even need invokeDynamic most of the time, because in most cases method calls in Clojure are only polymorphic and not dynamic. And because most things in Clojure are immutable. JRuby would have been a better example.

EDIT: formatting (moved ending paragraph to the beginning)

</comment></comment></comment><comment><USER42> There are a ton of reasons for me not to like Java but on top of it all it's how it clings to "object oriented niceness" in utterly stupid ways. It shoves its paradigm down your throat and there's nothing you can do about it. Starting with "You can't even have a Hello World program without a class" and eclipsing in the horrid madness that is the Java Standard Library.

Don't get me wrong, there is a time and place for OOP as well as for GoF design patterns but overdoing it is - I think - really bad design. Java tries to force you to adapt to this, while for certain tasks a different approach is clearly superior. Some programs benefit hugely from being written in a functional style, others benefit from having purely imperative modules that are _not_ part of a class hierarchy. Java doesn't do any of that and makes it look like a good thing.

Again, I don't condemn the idea of OOP, I condemn sticking too closely to one paradigm. C++ is a horrible language in many ways but I still prefer it to Java by miles. Because it's multi-paradigm. Python - multi-paradigm. Heck, even C99 is multi-paradigm in a way (assuming you dive deeply enough into it, one can actually write OOP code as well [1]).

</rant>

[1] www.cs.rit.edu/~ats/books/ooc.pdf

</comment><comment><USER43> The main problem I ever saw while attempting to migrate legacy(mainframe/db2) to modern (linux/java/oracle :)) systems was coupling.. there is so much customized, non documented, completely forgotten coupling between systems that is like changing engines on a plane (While flying!).

I takes a lot of patience, attention to details, and computer arqueology skills. Still, it can be done, and it is very worth it $$ to the companies (and to me! $ :)

</comment><comment><USER44> I hate java.

I love the JVM.

90% of the benefits of java are benefits of the JVM.

the Java language itself is garbage though. Too many hacks, too slow release cycle, too slow adoption cycle.

Kotlin is actually a great language built on the JVM that handles the weaknesses of Java and builds on the strengths of the JVM.

So once again, I am sick of articles "Java s0x0rs!" and "Java r0x0rs!" Please be specific as to what is a problem Java or JVM, and address that.

The only issue I have with Java is the JVM's garbage collector. I hate that the JVM's GC can't automatically expand and collapse the total allocated space to make your application run as lean as possible, but also expand to take up as much ram as needed. And by the time OutOfMemory exception is thrown, you are screeeeewed, best u can do is die. Wish there were strategies for out-of- memory handling (like which memory can be scrapped in favor of application stability)... then again you probably have a well designed app at this point.

</comment><comment><USER45> Everyone has preferences and opinions. There's nothing wrong with disliking to work with any language because of how you feel when working with it. Hating a language itself is a bit different though, they all had, or have its uses (well, there obviously are small exceptions), and I don't think many experienced programmers would claim that they actually hate a language itself.

No language is optimal for every single type of project and workstyle, and knowing only one language you wont get far in most situations, and thats fine. However if I see a choice I can make between java and another language to use at work for what I'm working on, I do end up using java in most cases simply because I enjoy working with it more.

</comment><comment> nic-ferrier The OP is absolutely spot on, however, innovation in those fields he mentions is very hard because they tend to be closed shops. I think the best thing those places could do would be to talent buy some startup teams and see what happens because it's sure as hell true that their existing IT is failing to move with the times.

Witness the ridiculous mess the British banking industry has gotten into (with RBS, a massive British consumer bank having a failure that caused them weeks of further problems).

It can often seem to those of us outside that management in those companies has focussed on pure profit, not dealt with technical debt and not even tried to make an effort to adapt their IT strategy to the rest of the world.

</comment><comment><USER46> Did anyone notice that the industries described are dominated by players who hate their customers? Banks and insurance companies treat their customers as adversaries, and the only reason they can do it is because they all do it Before we talk about solving the technological problems in these industries, we should be talking about solving these industries. The disruptors will solve the technology problems. I sure hope no one at Bank of America or AIG never attempt to shift their legacy systems to more elegant solutions. I want it to be one of the many albatross hanging around their neck.

</comment><comment><USER47> So what's the best path forward? I'm interested in building new models on top of existing software infrastructure (for the financial industry), not because I like brain damage, but because I'm very interested in finance.

If its a given that the industry is "antiquated and ridged" there has to be some room for people to solve existing problems. Even if it's laying new on- top of old (as some have mentioned). The question is: how do you identify the problems without going to work for a legacy infrastructure provider / integrator? Any advice out there?

</comment><comment><USER48> Many people claim Java gives better performance. I would like to know from some experienced programmers how it had been a few years ago. Was Java always this well performing?

Seems like Java community did quite a lot to get Java to perform better. How likely is it for a language like Python or Ruby to do something like that? I understand that these are vastly different technologies and we simply can't compare implementing a JVM feature in say a Python interpreter, but any commentary would be appreciated.

<comment><USER49> Sun hired some of the best minds in the business to make Java perform around 1999 - literally the guys that wrote the first runtime optimizing compilers and generational garbage collectors (eg. David Unger and team from Self), and also had some of the pioneers in LISP (Guy Steele). The major performance gains began in Java 1.3 in 2000 through Java 5 in 2004, with steady gains since, particularly in terms of garbage collection in large-memory, multi-core environments.

IBM also had some very bright minds working on their J9 JVM which was aoriginally targeted at embedded environments but was so good it became their mainstream VM. I'm not sure how much "borrowing" it does from the Oracle VM, but it's definitely a different architecture.

Another language could do this of it had wealthy patrons with a keen interest to make it so. Google with Python might be a possibility, but they are huge Java users already and have some of the old Sun team working for them.

<comment><USER50> Google started with Python with Unladen Swallow, but stopped after a combination of uninspiring results and the fact that while Google uses a lot of Python internally, it's generally for non-performance-critical applications. For the cases where performance counts, it's generally done in C++ instead.

</comment></comment></comment><comment><USER43> Quick example of legacy architecture tricling all the way up to today's java code: as of 2005 the largest travel network in the world, still used bit twirling on a byte to record the frequencies of flights.. on a flat file! 10000000 - monday 10100000 - monday and wednesday and so on ...

of course there was no documentation whatsoever to figure out what was going on :)

<comment><USER51> Many languages support using a bit vector as a set of enumerated values. Loading this byte into a suitable variable and checking it in the language debugger would be clear.

</comment></comment><comment><USER52> I must link this here:

NACA: Automatic migration from COBOL to maintainable Java -- <http://code.google.com/p/naca/>

"4 millions lines of COBOL were 100% automatically transcoded toward their Java equivalent."

I think this is a really cool technology.

</comment><comment><USER53> I couldn't care what language industries use. As long as they expose a better API than transferring damn text files and I don't have to wait 15 minutes for a response, I'm happy.

</comment><comment><USER54> The article is interesting on the whole regarding industries dragging their feet... but it didn't seem like it had much to do with Java.

</comment><comment><USER55> that's the repost. original link here: <http://thecodemechanic.wordpress.com/2011/05/30/hate-java/>

</comment><comment><USER56> I work in the banking industry and agree 100% on the mainframe usage and costs. There is a vudu/cult following that stack that likes to keep itself away from any controversy and keep a low profile. The biggest winner in this is IBM.

<comment><USER47> so where do you think the biggest areas are for improvement?

</comment></comment><comment><USER57> This post is a complete non-sequitur. You can hate Java AND hate antiquated practices. They're not mutually exclusive and there's plenty of room for more hate in this ol heart of mine.</comment>


Only 4% of Languages Are Used Online - <AUTHOR> http://priceonomics.com/only-4-of-languages-are-used-online/ <comment><USER2> Languages are tools for communication. Online, we have a much larger community to communicate with, so network effects apply for languages as well.

I don't think it's troubling that languages rise and fall, and many die out. Rather, it's the intangible heritage of humanity and particular cultures in danger that should attract our attention. Language is an element of this, but more important is the substance of their stories, their oral and written traditions, their values, and their way of live. We should work on preserving this heritage possibly at the expense of their language, if that's our only viable method.</comment>