I think much of "safe" programming is analogous to writing a FAQ before anyone asks a question. I like lib writers that provide clear error messages in their code, but too much just makes the code hard to read. A good programmer should be able to identify common errors and make their library raise help messages when these occur. That's all we really need. If the user is dumb enough to wrap calls to your lib in a catch-all begin-rescue-end block during development they deserve the frustration. As far as Java users being dumb, I don't know. I think it's more like trying to achieve the same goal in a different way.
Got milk?
raise "milk can't be nil" unless options[:milk]
Someone
· 2 years ago
...And ruby people must be assholes. As this blog entry proves way to well.
Pat
· 2 years ago
Someone: I'm sort of guessing that you only read the title. I don't actually think that Java people are stupid. I've just noticed this really weird trend among Java programmers moving to Ruby to assume that the people they work with are stupid.
The message, ultimately, is to educate rather than insulate. That's a theme you'll find pretty common in the Ruby community. What do you find assholish about that?
Giles Bowkett
· 2 years ago
No way, Pat, I read your blog under normal conditions, and I don't agree at all. It's not really stupid people, it's people who've accepted a stupid idea. Java's design is based on the idea that a language can prevent misuse by making bad things hard to do. It's defensive thinking. Java people are caught up in this paradigm; that's where these questions come from.
It might be more accurate to say that Java people are smarter than they give themselves credit for.
The thing is, telling people they're stupid, when their problem is an equal mix of bad ideas and defensive thinking, that's not the most persuasive argument available.
I think the only compelling argument, from a Java perspective, at least, in terms of Java people I've talked to, is that nobody ever actually accesses the stuff inside Rails which, if it were inside Java, would be hidden. The door isn't locked, but still nobody goes in.
In any OOP language you do want to keep client programmers only using the API, not the internals of the objects the API is made of. That's a good design principle. Java makes it happen by building a fort, locking everything down, the theory being they can't steal it if it's nailed to the floor. Their goal is legitimate, but their way of achieving it is kind of paranoid. Ruby's got the same goal, but a radically different approach to achieving it. It doesn't enforce any kind of security, but makes it easy to build such elegant APIs that entering the "forbidden zone" never even occurs to people, because it just isn't necessary.
It's like the opposite of thinking defensively isn't thinking offensively; the opposite of thinking defensively is thinking *creatively*.
Kurt Christensen
· 2 years ago
I totally agree with you about dynamic vs. statically-typed variables, except for one thing: corporate IT departments have already been down this road before - it was called Visual Basic. And for anything larger than a very trivial database front-end, it was a maintenance nightmare. That's all I'm saying.
Someone
· 2 years ago
Pat,
I read your whole blog entry, and I found it arrogant, and mean spirited. I can make 101 arguments why static type checking increases code maintainability, prevents runtime errors, makes code easier to write when dealing with unfamiliar libraries, and makes tools more useful. I don't know how many times I have had a problem show up in ruby at runtime that would have easily been caught by a good Java IDE as soon as the problem was created.
Calling people idiots, and stupid because they think static type checking is a good thing is just uncalled for. There are many very good arguments for static type checking.
Dave
· 2 years ago
@Giles: people reach into Ruby and Rails *all* the time precisely to *create* the elegant APIs you talk about.
Ruby allows you to lower the entry barrier to API programming *because* it lets you add or modify willy-nilly.
"Type-safety" and "block-boxing" are the arguments I hear the most when defending Java. If I'm dealing with Johnny McOutsource that might be a valid concern: ignorance or stupidity.
If I'm programming with people that are unwilling to, or incapable of, learn how to use Ruby *the way it was intended* then with any luck I'll be working with other people soon.
"Stupidity" may be a *harsh* way to put it, but it's still accurate.
Arto Nieminen
· 2 years ago
Listen, boy. Here's a nickel. Get yourself a better programming language: http://www.haskell.org
Dave
· 2 years ago
@Someone: There simple aren't *many* good, and even fewer *very* good arguments for static type checking. I can think of exactly two; pre-execution pseudo-type validity and black-boxing.
I'll take you up on your "101 reasons..." challenge. I also don't know how many times you've had problems show up at runtime that would have been caught by a good IDE, but it's a pretty rare occasion *I* have, and for most things, it's *my* experience I care about.
Pat
· 2 years ago
I don't think Java programmers are stupid! I don't think static typing is stupid, and I don't think people who like static typing are stupid. I understand that there are benefits to static typing and I know when it's useful. That's not what this post was about!
My point is that programmers are *intelligent* people and should be treated with respect. Part of that is trusting them to make the correct decisions. If you don't think they'll make the correct decisions, you should _teach them the correct way_ rather than hinder their abilities.
At no point in my post did I call people idiots for liking static typing. Seriously, take some time to reread it.
Pat
· 2 years ago
Obviously the confusion lies with the title. I thought it would be clear what I meant by
_Concerns like these all seem to boil down to one major theme: The people I work with are stupid._
So let me make things *perfectly clear*: I don't think Java people are actually stupid. I'm just amazed that Java programmers all seem to think their coworkers are stupid. The title of this post was meant to draw attention *only* to that fact.
Whatever
· 2 years ago
Every programmer, including the geniuses and deities amongst us, makes the occasional mistake.
Unit testing was invented to help detect these mistakes as quickly as possible.
Strangely enough, the fact that old-school compilers all had built-in automatic error detection just isn't good enough for some people.
The idea that only idiots have any use for automated testing seems kinda strange.
"Stupid" is a word better used to describe people arrogant enough to assume absolute perfection in their own code, because inevitably they'll be unwilling or unable to actually do anything about their own mistakes.
Someone
· 2 years ago
Dave,
If you are the Dave I think you probably are (Dave Thomas?) then thank you for contributing the whole two reasons you can think of for static type checking. However, we all know you are not exactly an objective source when it comes to the Ruby vs. Java debate. now are you.
I was naturally exagerating when I said 101 reasons. But I can come up with a lot of reasons, which I will try to list when I get off work.
Pat
· 2 years ago
Actually let me give a quick example from some of my own personal experience.
Early on when I was still coding Java, I was working on a project that had really intricate object structures. I had basically no clue how to combine the classes usefully, it was a real pain.
After lots of frustration, I asked one of the other developers how he managed to use the classes. He took a look at my code, laughed, and showed me a builder class they used.
One approach would have been to hide all constructors, so that the only way to instantiate objects was through the builder. Of course they realized that it may be useful to instantiate objects directly at times, so there’s no sense in completely preventing that.
Instead of preventing me from making mistakes, these developers let me make them and then showed me a better way. This is a small, trivial example, but not only was I using the library correctly, but I also understand how, when, and why to use Builders.
That’s what I’m suggesting here. You shouldn’t lock people down in a fort. You should let them make mistakes and then guide them along. And you can do that in ANY language. Freedom and respect for programmers is philosophy, not a language construct.
Nobody
· 2 years ago
Err... the Ruby community has (had?) a great reputation for friendliness. It's really not necessary to call people idiots just because they don't fully get dynamic typing, and it's certainly not the Ruby way -- at least the way that I've known and witnessed.
Giles Bowkett
· 2 years ago
@Pat - I predict many many more angry comments. People will read every word you wrote but the title will weigh so heavily in their minds they'll interpret those words in ways you never intended. Could be a real nightmare.
@Dave - yeah, but again, they reach in to create APIs, not to circumvent them.
@Everybody! There's a lot more to understanding Ruby than intelligence or stupidity. I've met very intelligent people who didn't understand programming at all. I think any programmer who ever leaves their house will do the same thing sooner or later. It generalizes up from there. Criticizing smart Java people who don't understand Ruby is like criticizing smart Americans who don't speak Japanese. It's got nothing to do with intelligence, it's just where you're coming from.
Shane
· 2 years ago
It's funny. All the people who are taking offense to the article because of its provocative title are almost confirming the very negative assertion that was _not_ made by the author. I grant that the title did not set one up to be sympathetic if one is using Java, but I think the author did an excellent job discussing the mindset of many Java programmers toward their fellow programmers.
Boring
· 2 years ago
The problem is, the people you work with *are* stupid. There's always someone learning, always one cowboy coder, always one guy who uses white lies liberally, etc, etc, etc.
You can't claim to know teams when you spend your nights coding your very own Ruby app; Put it into team of 15 people under strong business drivers and lets see what people say about "not coding with stupid people".
Once again, The Ruby community thinks it's god. Meanwhile the rug is being pulled from under their feet...
Pat
· 2 years ago
Someone: Go ahead and tell me where I called anyone stupid. That's the challenge, find a single part of my post where I declare someone an idiot. You won't find it, I guarantee it.
The only people calling Java programmers stupid are Java programmers themselves!
Here is my message, in bite-sized chunks, for those people unable to get past the title before hitting reply:
* It is a programmer's right to use his judgment when coding * It is your responsibility to assist and instruct a programmer when his judgment is misguided * Mistakes are natural and desirable. That's how we learn. Use mistakes as an opportunity to teach critical concepts, rather than let those concepts be hidden by safeguards * These rights and responsibilities are universal to programming, and are not unique to any language. The only thing that can hold those back is your own attitude.
This has NOTHING to do with Ruby vs Java, static- vs dynamic-typing, or anything at all related to a language war. It's all about having respect, compassion, and faith for your fellow programmers. It's about being passionate and proud of what you do, and going the extra mile to share your ideas with others.
Tomas Jogin
· 2 years ago
Funny thing! Those who kneejerkingly responded in the spirit of "no, I'm not stupid just because i like static typing" are actually too stupid to understand the real meaning of this post.
Doh!
jesse
· 2 years ago
Hmm, I certainly see where you're coming from, but...
I program games, which isn't very similar to web aps as there's not as much of a bend on security, and we build most of our own systems. Though there are certainly are some similar issues. But, I've always found, that, no matter how smart I think I am, the moment I think I have something figured out and can coast, I don't, and I learn the same stupid lessons over again. And with the loose type checking, never crash part of scripty languages, I get that sensation, and it scares me. They are nice and fun when I'm wipping up a util or personal app, but I'm really afraid of running them for anything serious. I would at least think some kind of verification layer would be nice for them, or maybe that already exists? I don't see any reason a psuedo/real compiler can't be run over them in some form, Python has this for speed doesn't it? Also, you got me to your article with the title (java: good idea, no follow through), I do most things in C/C++, and prefer C#. Haven't played much with Ruby yet... maybe that makes my post pointless?
Dave
· 2 years ago
@Someone: Nope, I'm just a random Dave. (And I do have another couple of reasons why static typing is good. Unfortunately I have *more* reasons why it's a PITA and I'm happier without it.)
@Giles: No, people reach in both to create *and* to circumvent, because writing APIs is hard. But I'd rather say "extend" than "circumvent", as extension seems to be the most common usecase.
bob
· 2 years ago
Giles wrote:
"It doesn’t enforce any kind of security, but makes it easy to build such elegant APIs that entering the “forbidden zone” never even occurs to people, because it just isn’t necessary."
Now, I don't profess to be a Ruby expert (or even a Ruby dabbler), but this statement floors me. Every malefactor out there must be salivating when they read about things that are unlocked because properly-motivated people wouldn't "need" to break in.
Who
· 2 years ago
I am a Java developer and I think Pat has some valid points - I dont think he was calling me stupid, just pointing out that there are different ways of percieving things and that basically we shoud be open to new ideas.
There are very few real 'liberal' individuals when it comes to programming it seems .
You guys have so many interesting things to say but you are so passionate about your respective fields it clouds the kernals of truth within your thoughts.
Dave
· 2 years ago
@bob: There's a difference between breaking in to an application and breaking in to an API.
A Rails webapp user wouldn't be able to "break in" to either the app or the code.
In addition, there are several ways to make a class final or closed so that if you didn't have access to the base-level code you couldn't wreak havoc malevolently via subclassing.
Klondike
· 2 years ago
Pat -- the part of your post where you called someone stupid...is the title. Even if your post body doesn't reaffirm the title in the way the title comes across, as *you are still responsible* for how the title makes people feel. It sets the tone for your entry.
I agree with nearly every one of your points inside the body, but I don't agree with the title. And that seriously weakens the post body. It's not about people "not reading past the title". It's that your attention-getting title sets a bad tone for the post to follow.
Jeremy McAnally
· 2 years ago
"I would at least think some kind of verification layer would be nice for them, or maybe that already exists?"
It's called testing. :) I contend that anyone who says static type checking is essential doesn't know how to write good tests (and, yes, you should be writing tests for that regardless of static or dynamic typing).
There exist a number of places where you can fool Java or C# or whatever into thinking that its static typing has it all figured out, when, in fact, it does not. I know from some very annoying experiences that this is true. This is why testing is so essential, and if you're going to write tests, then why bother with static type checking? It's silly, because at that point you gain nothing. The advantages of a dynamic language so far outweigh the tiny degree of security that type checking offers me that I can't imagine ever going back if I don't have to.
Ryan
· 2 years ago
Klondike: It is beyond absurd to believe that the author is _responsible for someone else's emotions_.
I agree that the title sets a poor tone. When I reread the title after the post, it doesn't look like an assertion of fact or even his opinion. It sounds to me like he's shrugging when he says it.
Pat: you write, "Go ahead and tell me where I called anyone stupid[1]. That's the challenge, find a single part of my post where I declare someone an idiot[2]."
[1] "If you need to protect someone on your team from code [...] the person is stupid." [2] "[Ruby] certainly doesn't need static type checking. What we need is to kick the idiots out [...]"
So, you are certainly calling a class of programmers "stupid idiots." I wouldn't say you're calling Java programmers stupid idiots, exactly. You're calling anyone who's ever made the sort of mistake that a language feature such as static typing would catch, a stupid idiot. That is a rather large subset of all programmers; I'd wager it may be as large as {All Programmers - Pat}. This is call hubris.
Roger
· 2 years ago
Pat: you write, "Go ahead and tell me where I called anyone stupid[1]. That's the challenge, find a single part of my post where I declare someone an idiot[2]."
fn1. "If you need to protect someone on your team from code [...] the person is stupid." fn2. "[Ruby] certainly doesn't need static type checking. What we need is to kick the idiots out [...]"
So, you are certainly calling a class of programmers "stupid idiots." I wouldn't say you're calling Java programmers stupid idiots, exactly. You're calling anyone who's ever made the sort of mistake that a language feature such as static typing would catch, a stupid idiot. That is a rather large subset of all programmers; I'd wager it may be as large as {All Programmers - Pat}. This is call hubris.
Pat
· 2 years ago
Roger: Creative use of quotations!
If you _properly_ quoted my post, you’d say that your fellow programmers are _either_ stupid _or_ naive (inexeperienced). You’d also highlight the fact that I think *most programmers fall into the second category* – i.e. we should help them out, rather than just dismiss them.
Real idiots don’t help the industry at all. Just like they don’t help any industry. I don’t see why that’s such a controversial issue. I’m suggesting though that *most programmers are capable* and that when they screw up, we should help them out. I certainly wouldn’t have learned anything meaningful if it weren’t for people with that attitude.
All programmers make mistakes, that's how we learn. I make mistakes several times throughout a single day, and I have no shame for it!
There's no hubris here. I just wish people weren't so fucking dumb that they turn this post into something that it isn't. It's like they're just looking for excuses to waste time and energy. I'd rather be coding.
P.S.: Have you noticed how nobody has really responded to my challenge? Especially “somebody,” who was so adamant about me being an asshole. He couldn't find a part of my post where I actually proclaimed someone stupid, but he _did_ manage to bring up his *high school test scores*.
Jesse Barnum
· 2 years ago
I don't know Ruby; I do know Java quite well, so I may make some assumptions in this letter about weakly/dynamically typed languages that are incorrect.
I am more productive because of strong type checking. I can say to myself, you know, this LoginManager class ought to take a String username and a char[] password, instead of a String password. I change it. I compile. The compiler shows me 5 places where this won't work. I fix it. I'm done.
Let's say that I want to rename 6 badly-named and rarely used methods in my LoginManager class, and then I get a phone call in the middle of this. I can take the phone call, leave for a meeting, come back to my project tomorrow, compile, and see exactly what I broke. In a weakly-typed language, if I forget the next day to do a find-and-replace, these missing methods would just sit there until they were called a month later and then break on a deployed application.
One of the arguments made about test cases is that they give you the flexibility to freely change your code, knowing that the tests will fail if you break something. Ruby users seems to get this. Now apply the exact same logic to the compiler - you have the flexibility to rename, remove, and change method signatures, knowing that the compiler will fail if you break something. Think of it as whole bunch of tiny test cases that are written for you automatically with no effort.
I feel that I am individually more productive because of this. But in addition to my own personal productivity, I am the lead developer on a team of 5 developers, some of whom work on the other coast, and now imagine the difficulty involved with one of these developers freely changing and refactoring their code libraries without strong type-checking.
Stupidity has nothing to do with it: I'm smart enough to know what weakly-typed languages are good for, what it's they're not good for.
Pat
· 2 years ago
Hey Jesse,
Thanks for your thoughtful comment. I definitely understand that there are some benefits to static typing. Like anything else in programming, we look at the tradeoffs of various approaches and figure out what works best in a given situation.
I'd just like to point out that my post wasn't about static typing at all, nor was it an attack on it...which makes me wonder why so many other people managed to get pissy about that particular topic.
Pat
raichu
· 2 years ago
if you think your title's causing all this misunderstanding, then JUST FIX IT. SERIOUSLY. there are better ways to express this microcontent, and it can help probably help you get your point across better. it's really easy compared to all the headaches caused by the confusion. after all, unlike in traditional publishing, you can actually fix your stuff online even after you're done.
or, if you're more into the traditional methods, just hire an editor, the ultimate lifesaver of writers everywhere.
Jesse Barnum
· 2 years ago
"I’d just like to point out that my post wasn’t about static typing at all, nor was it an attack on it…which makes me wonder why so many other people managed to get pissy about that particular topic."
To me, it seems that this post is making two points (not in this order):
1) You should not try to protect stupid people from themselves, you should get rid of them and hire smart people.
Agreed.
2) The main purpose of static type-checking is to protect stupid people from making mistakes.
Strongly disagree, for the reasons I previously mentioned. If this is not what your post is about, then by all means feel free to correct my misunderstanding, but the beginning and end of your article (specifically paragraphs 1-3 as well as the last paragraph) certainly give me that impression.
lhe
· 2 years ago
thank you for calling me stupid. unsubscribe. plonk.
Daniel Wintschel
· 2 years ago
Pat,
From a Java guy, and a Ruby guy - I couldn't agree with you more. It really boils down to choosing the right technology for the problem at hand. And, sterotypically speaking, what I've seen from most members of the Java community is a complete and utter disregard, maybe even disdain, for any language that is "not Java".
I like Java, a lot. But I like Ruby a lot, too. And I'll use them both, but instead of choosing a technology for the sake of being a zealot, I'll choose it for the sake of what's best for my client/customer/end user/whatever.
Thanks Pat, this was a good read.
-daniel
Kieron Wilkinson
· 2 years ago
Giles Bowkett said: "It doesn’t enforce any kind of security, but makes it easy to build such elegant APIs that entering the “forbidden zone” never even occurs to people, because it just isn’t necessary."
I guess you don't work in the finance industry then. What you say is fine in many situations, what what if need that security/protection against misuse?
In an everyday situation, it is often more important to be able to demonstrate from a compliance POV that your code takes appropriate steps to prevent misuse, than there being much risk of it.
I don't want to plug some 3rd party API into my financial applications (like an API from a bank), which could possibly route through my code and send them back the trading algorithms I use. I want to lock down what they can do, which is easy enough in Java though isolation, tightly-written API's and the SecurityManager mechanism.
I guess this is a reason why Java would live on in the finance world...
I'm a Java-bod, but I love some other languages, Occam, Haskal. I also quite like PHP, though I feel dirty most of the time I use it. ;) My point is that although I appreciate the glorious usages of other languages, Java is currently my number one choice for enterprise development.
JavaDeveloper
· 2 years ago
I'm not concern that you are tech guy or smart enough, Actually I thought you are some stupid & naive man, the program should be strong enought to dealing with wrong inputs, if you think that's not worth it, then you are only play with toy.
Actually why you don't attack C++/C# or Any lang that is using in the serious place? all these langs are having type checking during compiling and runtime to make it "safer".
BTW, how can you require anyone that using your API have to know what you are hidding behind the API?
how can your code know "1"+"1" = "11" or "2"?
Someone
· 2 years ago
Ahhh...there's no programming like web programming. After all, where else can you find millions upon millions of worthless religious wars about who's language is better or who's framework sucks or who is stupid and who is not. I'll bet you won't find programmers who write firmware for medical equipment or aerospace sparing over their tool choices in such ways as web programmers. Web programmers must only exhibit such behavior as a coping mechanism to help them deal with the insignificance of their work when compared to actual useful software that benefits actual people.
Eric Kramer
· 2 years ago
Amen on your blog entry. Why design a language/paradigm for the lowest-common-denominator?
John
· 2 years ago
Maybe you should have titled this post: PHP People Must Be Stupid, less people would have gotten mad...
Andy
· 2 years ago
Any programmer who does not keep an open mind and use the right tool for the right task is stupid. Language wars and those who fight them are stupid.
All Comments
Got milk?
raise "milk can't be nil" unless options[:milk]
The message, ultimately, is to educate rather than insulate. That's a theme you'll find pretty common in the Ruby community. What do you find assholish about that?
It might be more accurate to say that Java people are smarter than they give themselves credit for.
The thing is, telling people they're stupid, when their problem is an equal mix of bad ideas and defensive thinking, that's not the most persuasive argument available.
I think the only compelling argument, from a Java perspective, at least, in terms of Java people I've talked to, is that nobody ever actually accesses the stuff inside Rails which, if it were inside Java, would be hidden. The door isn't locked, but still nobody goes in.
In any OOP language you do want to keep client programmers only using the API, not the internals of the objects the API is made of. That's a good design principle. Java makes it happen by building a fort, locking everything down, the theory being they can't steal it if it's nailed to the floor. Their goal is legitimate, but their way of achieving it is kind of paranoid. Ruby's got the same goal, but a radically different approach to achieving it. It doesn't enforce any kind of security, but makes it easy to build such elegant APIs that entering the "forbidden zone" never even occurs to people, because it just isn't necessary.
It's like the opposite of thinking defensively isn't thinking offensively; the opposite of thinking defensively is thinking *creatively*.
I read your whole blog entry, and I found it arrogant, and mean spirited. I can make 101 arguments why static type checking increases code maintainability, prevents runtime errors, makes code easier to write when dealing with unfamiliar libraries, and makes tools more useful. I don't know how many times I have had a problem show up in ruby at runtime that would have easily been caught by a good Java IDE as soon as the problem was created.
Calling people idiots, and stupid because they think static type checking is a good thing is just uncalled for. There are many very good arguments for static type checking.
Ruby allows you to lower the entry barrier to API programming *because* it lets you add or modify willy-nilly.
"Type-safety" and "block-boxing" are the arguments I hear the most when defending Java. If I'm dealing with Johnny McOutsource that might be a valid concern: ignorance or stupidity.
If I'm programming with people that are unwilling to, or incapable of, learn how to use Ruby *the way it was intended* then with any luck I'll be working with other people soon.
"Stupidity" may be a *harsh* way to put it, but it's still accurate.
I'll take you up on your "101 reasons..." challenge. I also don't know how many times you've had problems show up at runtime that would have been caught by a good IDE, but it's a pretty rare occasion *I* have, and for most things, it's *my* experience I care about.
My point is that programmers are *intelligent* people and should be treated with respect. Part of that is trusting them to make the correct decisions. If you don't think they'll make the correct decisions, you should _teach them the correct way_ rather than hinder their abilities.
At no point in my post did I call people idiots for liking static typing. Seriously, take some time to reread it.
_Concerns like these all seem to boil down to one major theme: The people I work with are stupid._
So let me make things *perfectly clear*: I don't think Java people are actually stupid. I'm just amazed that Java programmers all seem to think their coworkers are stupid. The title of this post was meant to draw attention *only* to that fact.
Unit testing was invented to help detect these mistakes as quickly as possible.
Strangely enough, the fact that old-school compilers all had built-in automatic error detection just isn't good enough for some people.
The idea that only idiots have any use for automated testing seems kinda strange.
"Stupid" is a word better used to describe people arrogant enough to assume absolute perfection in their own code, because inevitably they'll be unwilling or unable to actually do anything about their own mistakes.
If you are the Dave I think you probably are (Dave Thomas?) then thank you for contributing the whole two reasons you can think of for static type checking. However, we all know you are not exactly an objective source when it comes to the Ruby vs. Java debate. now are you.
I was naturally exagerating when I said 101 reasons. But I can come up with a lot of reasons, which I will try to list when I get off work.
Early on when I was still coding Java, I was working on a project that had really intricate object structures. I had basically no clue how to combine the classes usefully, it was a real pain.
After lots of frustration, I asked one of the other developers how he managed to use the classes. He took a look at my code, laughed, and showed me a builder class they used.
One approach would have been to hide all constructors, so that the only way to instantiate objects was through the builder. Of course they realized that it may be useful to instantiate objects directly at times, so there’s no sense in completely preventing that.
Instead of preventing me from making mistakes, these developers let me make them and then showed me a better way. This is a small, trivial example, but not only was I using the library correctly, but I also understand how, when, and why to use Builders.
That’s what I’m suggesting here. You shouldn’t lock people down in a fort. You should let them make mistakes and then guide them along. And you can do that in ANY language. Freedom and respect for programmers is philosophy, not a language construct.
@Dave - yeah, but again, they reach in to create APIs, not to circumvent them.
@Everybody! There's a lot more to understanding Ruby than intelligence or stupidity. I've met very intelligent people who didn't understand programming at all. I think any programmer who ever leaves their house will do the same thing sooner or later. It generalizes up from there. Criticizing smart Java people who don't understand Ruby is like criticizing smart Americans who don't speak Japanese. It's got nothing to do with intelligence, it's just where you're coming from.
You can't claim to know teams when you spend your nights coding your very own Ruby app; Put it into team of 15 people under strong business drivers and lets see what people say about "not coding with stupid people".
Once again, The Ruby community thinks it's god. Meanwhile the rug is being pulled from under their feet...
The only people calling Java programmers stupid are Java programmers themselves!
Here is my message, in bite-sized chunks, for those people unable to get past the title before hitting reply:
* It is a programmer's right to use his judgment when coding
* It is your responsibility to assist and instruct a programmer when his judgment is misguided
* Mistakes are natural and desirable. That's how we learn. Use mistakes as an opportunity to teach critical concepts, rather than let those concepts be hidden by safeguards
* These rights and responsibilities are universal to programming, and are not unique to any language. The only thing that can hold those back is your own attitude.
This has NOTHING to do with Ruby vs Java, static- vs dynamic-typing, or anything at all related to a language war. It's all about having respect, compassion, and faith for your fellow programmers. It's about being passionate and proud of what you do, and going the extra mile to share your ideas with others.
Doh!
I program games, which isn't very similar to web aps as there's not as much of a bend on security, and we build most of our own systems. Though there are certainly are some similar issues. But, I've always found, that, no matter how smart I think I am, the moment I think I have something figured out and can coast, I don't, and I learn the same stupid lessons over again. And with the loose type checking, never crash part of scripty languages, I get that sensation, and it scares me. They are nice and fun when I'm wipping up a util or personal app, but I'm really afraid of running them for anything serious. I would at least think some kind of verification layer would be nice for them, or maybe that already exists? I don't see any reason a psuedo/real compiler can't be run over them in some form, Python has this for speed doesn't it? Also, you got me to your article with the title (java: good idea, no follow through), I do most things in C/C++, and prefer C#. Haven't played much with Ruby yet... maybe that makes my post pointless?
@Giles: No, people reach in both to create *and* to circumvent, because writing APIs is hard. But I'd rather say "extend" than "circumvent", as extension seems to be the most common usecase.
"It doesn’t enforce any kind of security, but makes it easy to build such elegant APIs that entering the “forbidden zone” never even occurs to people, because it just isn’t necessary."
Now, I don't profess to be a Ruby expert (or even a Ruby dabbler), but this statement floors me. Every malefactor out there must be salivating when they read about things that are unlocked because properly-motivated people wouldn't "need" to break in.
There are very few real 'liberal' individuals when it comes to programming it seems .
You guys have so many interesting things to say but you are so passionate about your respective fields it clouds the kernals of truth within your thoughts.
A Rails webapp user wouldn't be able to "break in" to either the app or the code.
In addition, there are several ways to make a class final or closed so that if you didn't have access to the base-level code you couldn't wreak havoc malevolently via subclassing.
I agree with nearly every one of your points inside the body, but I don't agree with the title. And that seriously weakens the post body. It's not about people "not reading past the title". It's that your attention-getting title sets a bad tone for the post to follow.
It's called testing. :) I contend that anyone who says static type checking is essential doesn't know how to write good tests (and, yes, you should be writing tests for that regardless of static or dynamic typing).
There exist a number of places where you can fool Java or C# or whatever into thinking that its static typing has it all figured out, when, in fact, it does not. I know from some very annoying experiences that this is true. This is why testing is so essential, and if you're going to write tests, then why bother with static type checking? It's silly, because at that point you gain nothing. The advantages of a dynamic language so far outweigh the tiny degree of security that type checking offers me that I can't imagine ever going back if I don't have to.
I agree that the title sets a poor tone. When I reread the title after the post, it doesn't look like an assertion of fact or even his opinion. It sounds to me like he's shrugging when he says it.
[1] "If you need to protect someone on your team from code [...] the person is stupid."
[2] "[Ruby] certainly doesn't need static type checking. What we need is to kick the idiots out [...]"
So, you are certainly calling a class of programmers "stupid idiots." I wouldn't say you're calling Java programmers stupid idiots, exactly. You're calling anyone who's ever made the sort of mistake that a language feature such as static typing would catch, a stupid idiot. That is a rather large subset of all programmers; I'd wager it may be as large as {All Programmers - Pat}. This is call hubris.
fn1. "If you need to protect someone on your team from code [...] the person is stupid."
fn2. "[Ruby] certainly doesn't need static type checking. What we need is to kick the idiots out [...]"
So, you are certainly calling a class of programmers "stupid idiots." I wouldn't say you're calling Java programmers stupid idiots, exactly. You're calling anyone who's ever made the sort of mistake that a language feature such as static typing would catch, a stupid idiot. That is a rather large subset of all programmers; I'd wager it may be as large as {All Programmers - Pat}. This is call hubris.
If you _properly_ quoted my post, you’d say that your fellow programmers are _either_ stupid _or_ naive (inexeperienced). You’d also highlight the fact that I think *most programmers fall into the second category* – i.e. we should help them out, rather than just dismiss them.
Real idiots don’t help the industry at all. Just like they don’t help any industry. I don’t see why that’s such a controversial issue. I’m suggesting though that *most programmers are capable* and that when they screw up, we should help them out. I certainly wouldn’t have learned anything meaningful if it weren’t for people with that attitude.
All programmers make mistakes, that's how we learn. I make mistakes several times throughout a single day, and I have no shame for it!
There's no hubris here. I just wish people weren't so fucking dumb that they turn this post into something that it isn't. It's like they're just looking for excuses to waste time and energy. I'd rather be coding.
P.S.: Have you noticed how nobody has really responded to my challenge? Especially “somebody,” who was so adamant about me being an asshole. He couldn't find a part of my post where I actually proclaimed someone stupid, but he _did_ manage to bring up his *high school test scores*.
I am more productive because of strong type checking. I can say to myself, you know, this LoginManager class ought to take a String username and a char[] password, instead of a String password. I change it. I compile. The compiler shows me 5 places where this won't work. I fix it. I'm done.
Let's say that I want to rename 6 badly-named and rarely used methods in my LoginManager class, and then I get a phone call in the middle of this. I can take the phone call, leave for a meeting, come back to my project tomorrow, compile, and see exactly what I broke. In a weakly-typed language, if I forget the next day to do a find-and-replace, these missing methods would just sit there until they were called a month later and then break on a deployed application.
One of the arguments made about test cases is that they give you the flexibility to freely change your code, knowing that the tests will fail if you break something. Ruby users seems to get this. Now apply the exact same logic to the compiler - you have the flexibility to rename, remove, and change method signatures, knowing that the compiler will fail if you break something. Think of it as whole bunch of tiny test cases that are written for you automatically with no effort.
I feel that I am individually more productive because of this. But in addition to my own personal productivity, I am the lead developer on a team of 5 developers, some of whom work on the other coast, and now imagine the difficulty involved with one of these developers freely changing and refactoring their code libraries without strong type-checking.
Stupidity has nothing to do with it: I'm smart enough to know what weakly-typed languages are good for, what it's they're not good for.
Thanks for your thoughtful comment. I definitely understand that there are some benefits to static typing. Like anything else in programming, we look at the tradeoffs of various approaches and figure out what works best in a given situation.
I'd just like to point out that my post wasn't about static typing at all, nor was it an attack on it...which makes me wonder why so many other people managed to get pissy about that particular topic.
Pat
or, if you're more into the traditional methods, just hire an editor, the ultimate lifesaver of writers everywhere.
To me, it seems that this post is making two points (not in this order):
1) You should not try to protect stupid people from themselves, you should get rid of them and hire smart people.
Agreed.
2) The main purpose of static type-checking is to protect stupid people from making mistakes.
Strongly disagree, for the reasons I previously mentioned. If this is not what your post is about, then by all means feel free to correct my misunderstanding, but the beginning and end of your article (specifically paragraphs 1-3 as well as the last paragraph) certainly give me that impression.
unsubscribe. plonk.
From a Java guy, and a Ruby guy - I couldn't agree with you more. It really boils down to choosing the right technology for the problem at hand. And, sterotypically speaking, what I've seen from most members of the Java community is a complete and utter disregard, maybe even disdain, for any language that is "not Java".
I like Java, a lot. But I like Ruby a lot, too. And I'll use them both, but instead of choosing a technology for the sake of being a zealot, I'll choose it for the sake of what's best for my client/customer/end user/whatever.
Thanks Pat, this was a good read.
-daniel
I guess you don't work in the finance industry then. What you say is fine in many situations, what what if need that security/protection against misuse?
In an everyday situation, it is often more important to be able to demonstrate from a compliance POV that your code takes appropriate steps to prevent misuse, than there being much risk of it.
I don't want to plug some 3rd party API into my financial applications (like an API from a bank), which could possibly route through my code and send them back the trading algorithms I use. I want to lock down what they can do, which is easy enough in Java though isolation, tightly-written API's and the SecurityManager mechanism.
I guess this is a reason why Java would live on in the finance world...
I'm a Java-bod, but I love some other languages, Occam, Haskal. I also quite like PHP, though I feel dirty most of the time I use it. ;) My point is that although I appreciate the glorious usages of other languages, Java is currently my number one choice for enterprise development.
Actually why you don't attack C++/C# or Any lang that is using in the serious place? all these langs are having type checking during compiling and runtime to make it "safer".
BTW, how can you require anyone that using your API have to know what you are hidding behind the API?
how can your code know "1"+"1" = "11" or "2"?