Live data from Hacker News

Hopefully more controversial programming opinions

prog21.dadgum.com

41–50 of 103 posts

Re: Hopefully more controversial programming opinions

#41

Earlier quoted context omitted.

When I see int a; I read "create an integer variable called a". int *i; means, "create a variable that when dereferenced, points to an integer". Makes sense once you understand it, but I can definitely understand how a beginner would find it confusing.

It may be a problem with the teaching though, rather than the subject matter itself. I understand why it takes a little bit of thinking to get used to, but not why it is fundamentally hard. Now, algorithms can be difficult to understand and many of them use pointers... Do some people confuse the 2?

I don't think the difficulty is fundamental, and I don't think anyone here claimed that it was. But it is initially challenging nonetheless.

To tie this back in to the beginning of the thread, being able to understand indirection (such as in pointers and algorithms) is a far more important skill than understanding OOP.

Re: Hopefully more controversial programming opinions

#42

[update: I've got hold of some of the code. Here's a copy of one of the programmes http://pastie.org/4615158 ] I have an awesome story that i think I've told before, but I'll tell it again anyway :) My father-in-law is a pharmasist. back in the early 90s computers were starting to make their way into Pharmacy and the first few pharmacy sortware packages appeared. this increased with time, as you'd expect. At some poi…

Because understanding exactly what program should do is more important than understanding what are best practices in CS, or how to abstract things.

If you can keep all interactions of your app in your head, then it doesn't matter how badly designed the code is. Architecture is only important because it makes it possible to change things without understanding the whole thing.

And complete understanding with bad architecture beats good architecture with incomplete understanding.

Re: Hopefully more controversial programming opinions

#43
post #29

Earlier quoted context omitted.

This reminds me of a manager of mine who wrote a 10,000 line Perl script. He thought himself how to write Perl in a week. And then started coding. He wrote a script to automate a very tedious testing process so perfectly, we were able to reduce our test team by like 70% and test more precisely than before. It was fully procedural code. And it looked monstrous. Our architect challenged him that it won't workout. He ev…

The architect sounds obsessed with Java... first sign of craziness! Disclaimer: I like C/C++/Python.

Actually its all the 'design' craze. Most architects think drawing UML diagrams on mspaint to be a sign of technical superiority.

The real issue I think is heavy OO programmers(read java) can't live without.

1. Design patterns- The art of bloating already heavily bloated code.

2. Avoiding meta programming of any kind.

3. Love towards getters/settters and absolutely anything that lends to code bureaucracy.

Why get/set variable directly when you can write tens of classes of methods to set them?

4. Avoid learning the command line. And write bad implementations of sub functionalities of tools like awk/sed to achieve the same tasks.

5. Lengthen anything and everything as much as you can. thisIncludesTheVariableNames, Class names, methods names, package hierarchies, class inheritance. You name it they can pointlessly lengthen it.

6. If you write code in file at least 40% of the lines MUST be try/catch statements. If you can't be satisfied with that write your won exception classes and invoke point 5.

7. Always write code which can't be read or figured out unless you have auto complete, intellisense and other IDE goodies.

8. Use XML as much as you can so that you can dogfood your insanity even more.

9. Make the code so verbose that even simple programs sound like very complicated ones that can be written only by you.

and many more...

If you don't follow these points Java programmers/architects think you are writing bad code.

Re: Hopefully more controversial programming opinions

#44
post #13

"Superficially ugly code is irrelevant. Pretty formatting--or lack thereof--has no bearing on whether the code works and is reliable, and that kind of mechanical fiddling is better left to an automated tool." I disagree with this one. Clear, readable code is... clear and readable. It's like not bothering to format text in a textbook because "the meat of the matter is in there, so who cares?" Of course substance is mo…

I agree with you. What i took away from that point was to leave it to an automated tool. Th Eclipse Java formatter was the first time I saw this work. Distribute the formatter settings among your team, make everyone set the "format on save" option, be done with it.

I just wish all languages had this kind of support.

Re: Hopefully more controversial programming opinions

#45
post #9

Here's my version of his opinions, probably even more controversial :P. CS should be offered as a major by itself. All the most interesting stuff is CS-specific with indirect applications. Working on something like automatic programming is far more exciting than working on biology or art or what have you. (I can't think of anything more awesome or more CS-only than automatic programming.) It is a mistake to introduce…

I wouldn't be so quick to throw away the "software engineering mindset" quite so quickly. Part of an engineering mindset is roughly "I am prepared to stand up in court and defend all the choices I made designing this product to a jury of my peers". If we can get to that point, where there is a set of guidelines so clear, and so universally accepted, that you could get 12 arbitrary software developers to uniformly agree that the designer chose well in following them, and we could actually use them to do useful design work, that would be such a huge step forward that the profession would change unrecognisably.

We're not there yet.

Re: Hopefully more controversial programming opinions

#46
post #42

[update: I've got hold of some of the code. Here's a copy of one of the programmes http://pastie.org/4615158 ] I have an awesome story that i think I've told before, but I'll tell it again anyway :) My father-in-law is a pharmasist. back in the early 90s computers were starting to make their way into Pharmacy and the first few pharmacy sortware packages appeared. this increased with time, as you'd expect. At some poi…

Because understanding exactly what program should do is more important than understanding what are best practices in CS, or how to abstract things. If you can keep all interactions of your app in your head, then it doesn't matter how badly designed the code is. Architecture is only important because it makes it possible to change things without understanding the whole thing. And complete understanding with bad archit…

>Architecture is only important because it makes it possible to change things without understanding the whole thing.

And for that you need to understand the architecture, ofcourse.

You always need to understand something_(n-1) to understand something_n, ad infinitum

Re: Hopefully more controversial programming opinions

#47
post #40
post #24

Earlier quoted context omitted.

The problem with software trade schools, even though you may not require a pure maths focus, I still expect people who program professionally to be good at maths. I would expect most programmers to analyse algorithms in a formal manner if they have to. And the people capable of doing maths at that level are not the people that traditionally go to trade schools.

To make something fast or to make something scale you don't need a proof. You need a profiler.

To a certain degree, this is true. However, a profiler won't turn the DFT into the FFT.

Re: Hopefully more controversial programming opinions

#48
> Purely functional programming doesn't work, but if you mix in a small amount of imperative code then it does.

That isn't controversial nor is it an opinion. It's just the truth. Purely functional code has no side effects. The entire point of a program is to have side effects.

Re: Hopefully more controversial programming opinions

#49
post #31
post #16

Earlier quoted context omitted.

> Is it really a controversial opinion? I haven't heard anyone argue against it, but for a very long time every single curriculum out there started with either Java or C++, and had to talk about object quite early on (you can't print "hello world" in Java without it, and you can't use C++ streams either). And arguments I've heard about that practice as a proxy for your question, indicate that it is (or at least, was…

You must write a class in order to do "hello world" in Java. C++ streams don't require you to write a class, only use what appears to be a strange syntax. You can go a long way in C++ without defining any classes of your own.

You have to write a class to do "hello world" in Java, but you don't have to understand OO. If you just treat the class syntax as meaningless boilerplate you can learn a lot of programming concepts before needing to touch messaging.

Having seen 3000-line single-class Java monstrosities, I can assure you that this is not only true in theory.

Re: Hopefully more controversial programming opinions

#50
post #5

"You shouldn't be allowed to write a library for use by other people until you have ten years of programming under your belt. If you think you know better and ignore this rule, then one day you will come to realize the mental suffering that you have inflicted upon others, and you will have to live with that knowledge for the rest of your life." stunning.

I'm actually currently in process of writing a small library, but I have only 6 years of experience. I'm frightened.

Don't be intimidated. The only way to learn is to do.

Just keep in mind that a library takes a surprising amount of time to make "good enough".

The most frequent sin in library design is to knock something up in a weekend, check that it sorta works for you, and then consider it done.

Post reply on HN