Live data from Hacker News

Hopefully more controversial programming opinions

prog21.dadgum.com

91–100 of 103 posts

Re: Hopefully more controversial programming opinions

#91
post #74
post #43

Earlier quoted context omitted.

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…

I'm sorry, but your comment is really not much more than pointless, cynical Java bashing. Java has it's share of problems, and it's definitely not as modern (regarding language features) as some of the other languages today (although that seems to be changing too), but if you're going to attack it, then at least do it for it's bad characteristics, not because you personally dislike/don't understand certain features,…

It's true that Java is more bureaucratic than most languages, but there is a reason why getters and setters are the standard. And the reason is encapsulation

Zen tip: When there is a reason for a bad thing, that is called a bad reason.

Re: Hopefully more controversial programming opinions

#92
post #84

Earlier quoted context omitted.

So, the language choice of a piece of software determines the amount of time and money that is required to build the system?

So where you live has no bearing on crime levels?

So, you're suggesting the following analogy: The crime level of a region relates to the region itself the same way that the quality of software relates to the language the software is built on? You're comparing a property of an object to the object itself and a property of an object to another property. Pretty awesome you'd make that mistake in a thread where you're agreeing with someone's criticism of OO principles.

Re: Hopefully more controversial programming opinions

#93

Earlier quoted context omitted.

So, the language choice of a piece of software determines the amount of time and money that is required to build the system?

Of course it does. Why is this surprising? Try building a (safe) web app in C and see how long it takes.

The bit about building a web app in C is totally off-topic from your claim that 100 lines of python would equal 100 hrs of Java. If you can only write good software in a short amount of time in one or two languages, that's just a reflection of you as a developer and not the language, and I'd seriously challenge you to show me something you've written in 100 lines of python that I couldn't hire a single senior Java developer to write in the same amount of time (lines of code doesn't equal cost, so I'm not interested in debating lines of code nor do I think it's a valid measure of anything).

I'll give you a short story that approaches this issue from both sides. A client walks into a consulting shop with a piece of really bad client/server software written by a different consulting shop. The server is written in Ruby/Rails and the client in Java (Android). Both client and server code is horrible even though the server is written in Ruby (a supposedly beautiful/compact/expressive language) and the client in Java (super ugly long winded grandpa language, or whatever). The client paid the original consultants about $60k in total. One Ruby engineer and one Java engineer rewrote the entire thing in a few days for 1/20 the cost without really reusing an ounce of the original code. Ruby didn't stop the original server engineer from delivering horseshit in too much time, and Java didn't stop the second client engineer from delivering a clean/functional/performant app in just a few days.

Re: Hopefully more controversial programming opinions

#94

Earlier quoted context omitted.

Of course it does. Why is this surprising? Try building a (safe) web app in C and see how long it takes.

The bit about building a web app in C is totally off-topic from your claim that 100 lines of python would equal 100 hrs of Java. If you can only write good software in a short amount of time in one or two languages, that's just a reflection of you as a developer and not the language, and I'd seriously challenge you to show me something you've written in 100 lines of python that I couldn't hire a single senior Java de…

Your second paragraph is what I meant

But I've never seen a "software consultancy company" do a project except in Java

Ruby and Python can be beautiful yes, but in the hands of average Java programmers it just becomes a horrid mess

Re: Hopefully more controversial programming opinions

#95

Earlier quoted context omitted.

I read the grandparent as criticizing Java programmers . A sufficient number of bad programmers seem to fall in these trap often enough that the result is a mess. Design pattern: I wouldn't be surprised if they are used too much. Love towards getters/setters. Not the fault of the language, that's just bad practice. And no, you don't have encapsulation. Rarely, getters and setters do some verifications or filtering, b…

"In your example, I'd say the overly long name comes from an overly narrow functionality. For something that specific, you should use a description string." - What use is a description string when you're staring at a code listing, trying to figure out what it does? "a good IDE let you manage and tolerate higher levels of complexity." - Which is a good thing. "You'll also be less encouraged to simplify your code." - S…

1) This error looks like it can't be recovered from. Just throw UnrecoverableError("Config file not found"), and you're done. The code is just as readable. Now if you also need to easily catch it, you need better pattern matching than Java and C++ can give you (Ocaml works well). Again, the code will readily display the relevant string. With C++ and Java, okay, drop the string. But try to limit the scope of your exception to the module it belongs to, and use context to give it a shorter name.

2) I agree

3) Thinking about it… you're probably right.

4) I agree

My point was, IDEs are double edged. Like debuggers. Without such fancy tools, you are forced to think before you write nonsense to the compiler. Good programmers will do the thinking anyway, but many others need some "encouragement". Optimizing for good programmers is a good heuristic, but sometimes, you also need to prevent the bad ones to make too many mistakes.

A similar argument can be made about functional languages: I can avoid side effects in C++ just fine, and I mostly do because its plain simpler most of the time. But many programmers need at least an Ocaml straight jacket.

Re: Hopefully more controversial programming opinions

#96

[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…

The version given to me by my professor was: "Think like an amateur. Execute as an expert."

Originally by Takeo Kanade. ( http://www.cs.cmu.edu/interviews/kanade/ )

Re: Hopefully more controversial programming opinions

#97

Earlier quoted context omitted.

"In your example, I'd say the overly long name comes from an overly narrow functionality. For something that specific, you should use a description string." - What use is a description string when you're staring at a code listing, trying to figure out what it does? "a good IDE let you manage and tolerate higher levels of complexity." - Which is a good thing. "You'll also be less encouraged to simplify your code." - S…

1) This error looks like it can't be recovered from. Just throw UnrecoverableError("Config file not found"), and you're done. The code is just as readable. Now if you also need to easily catch it, you need better pattern matching than Java and C++ can give you (Ocaml works well). Again, the code will readily display the relevant string. With C++ and Java, okay, drop the string. But try to limit the scope of your exce…

OK, I thought you were taking exception(har har) to the name length, not to the fact that such an exception subclass was being used rather than simply filling in a description.

However, even then I think it's not quite so simple. In most cases simply putting in a text description for the exception would be sufficient, given language support when catching should it be needed. But if the application at a higher level needs to know what went wrong in order to inform the user in a friendly way, you'd need some kind of mapping between the exception and what to display on the screen. And if your app is internationalized, simply displaying the description of the exception would be even more problematic, especially if you have the same exception being thrown from different places (in which case you need to make sure none of their descriptions differ by even a single character lest you destroy the i18n mapping). I couldn't say definitely that subclassed exceptions would be superior in this case, but one could make an argument in favor.

Re: Hopefully more controversial programming opinions

#98
post #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.

"indent" the program (for C) has been around for a while.

The other nice thing about automated formatting is that everyone can edit code in their preferred format, as long as they convert it back before checking in (for readable diffs)

Re: Hopefully more controversial programming opinions

#99
post #88

Earlier quoted context omitted.

Not true. For example, a compiler can be a pure function. It accepts input that is the source code, and outputs the machine code. There's no side effect there. I admit it needs minor scaffolding to always read all of stdin first, and write all to stdout at the end, but the programme, as written by the programmer, is a pure function. This is one of several ways that Haskell worked before there was an IO monad [1], all…

Yes, the 'minor scaffolding' has side effects. That's why I said it wasn't controversial.

The side effects in the scaffolding are purely an implementation detail.

For non-interactive use (like a compiler) you could implement the program as a function taking and returning a string.

Re: Hopefully more controversial programming opinions

#100

Earlier quoted context omitted.

"In your example, I'd say the overly long name comes from an overly narrow functionality. For something that specific, you should use a description string." - What use is a description string when you're staring at a code listing, trying to figure out what it does? "a good IDE let you manage and tolerate higher levels of complexity." - Which is a good thing. "You'll also be less encouraged to simplify your code." - S…

1) This error looks like it can't be recovered from. Just throw UnrecoverableError("Config file not found"), and you're done. The code is just as readable. Now if you also need to easily catch it, you need better pattern matching than Java and C++ can give you (Ocaml works well). Again, the code will readily display the relevant string. With C++ and Java, okay, drop the string. But try to limit the scope of your exce…

Regarding 1)... Yes, in this particular case you could just throw an UnrecoverableError (or whatever) and pass a string with a message of what went wrong to its constructor. But that wasn't my point at all. I wasn't trying to make a point about how to structure code or deal with errors/exceptions, I was trying to make a point about naming conventions. My example could just as easily have been something like:

"PtgSL. PatagonianSeaLion. Which of these names describes the class better?"

Post reply on HN