In a larger project not only will type inference be weaker because you'll have a sea of your own, poorly annotated code, as opposed well-documented, well-annotated third-party code, but a bunch of people will check in code that runs but fails the type check according to your editor. And you'll have to get used to figuring out which red underline is an actual error and which is a pseudo error that your colleague refuses to fix because that's "your editor's problem."

I understand that you can structure your environment and write code in such a way that plays nicely with your editor, but in a larger team, you'll have a harder time policing everyone's behavior. There's a lot of value in having the compiler step up and be the final arbiter.

Our large team basically has a 2-tiered structure of "framework devs" and "feature devs". As a framework dev I actually find it quite satisfying to try to come up with a framework that's simple, intuitive, has the right amount of guardrails, and satisfies our unique needs - so the feature devs can just focus on functionality and business logic as much as possible.

Suzzer's post reminds me, do you have much experience working in a large team or are you extrapolating based on what you've heard and/or a little bit of bad experience? The lone wolf thing can be fun but does limit your potential as a developer.

^

No experience working with a large team on a regular basis. I've committed code changes to some open source projects though, but nothing huge.

My reasoning is you don't really need a team of 50 people and a 400,000 line code base to make a successful web service and I don't want to work for a wage at some massive corporation.

I am fully content flying solo and would also enjoy working with a few other developers on a project when the opportunity strikes.

The ******ed protection mechanism was a little out of line because it's much more than that in the grand scheme of things. I was just rudely stating that I shouldn't have to write more code because in the off chance someone makes a preventable error the compiler will save me.

Haskell, OCaml and Scala are more concise than Ruby, even with a few more type declarations. If you add in the type annotations and the additional tests you have to write that can be coded as types, it's not even close. Don't forget that these languages have type inference that's much more complete than RubyMine's and fully verified, that is if types are neither inferred nor declared, the code cannot run.

It's silly to talk about how much static typing as provided by your IDE (RubyMine has essentially created a pseudo-statically typed language using a combination of optionally provided type declarations and limited type inference) helps you with catching simple errors while decrying against a much more complete version of it that provides a much stronger guarantee, simultaneously for all your colleagues regardless of what editor they are using.

Don't forget, the reason you're getting nice errors and hints/autocomplete/etc such in RubyMine is because someone wrote additional code and type declarations to save you from a preventable error.

I mean when you're struggling with things like this:

http://youtrack.jetbrains.com/issue/RUBY-9142

You're not really playing the same game.

As mentioned previously it protects me from the most common errors (typo in the method name and wrong # of args) without extra annotations. All of my custom gems/modules/etc. have no annotations but it catches all of those mistakes automatically for me.

I also have never written a test where its sole purpose was to make sure someone is passing the correct arguments to it or is the right type. So it's not like I'm writing more tests due to the lack of types.

No it doesn't - that's impossible. It's either overzealously catching errors that aren't errors or leaving some uncaught. If this was possible, we can just call Ruby + RubyMine a statically typed language with full type inference. You're likely doing things that are mostly vanilla and easy for the type inference algorithm to deal with, like interfacing with Rails when RubyMine has the type information for public Rails modules. You're also missing the errors that aren't caught.

Put it another way, if type inference algorithm works so well in RubyMine, why are they supporting Rails as a special case and why are people complaining about not being able to annotate local/instance variables? Why is reading YARD for type annotations one of their selling points?

What's verifying the type errors that are not caught by RubyMine? You're aware that type checking is nowhere near complete, right?

It might be doing overzealous checking but it's doing it in a way that prevents mistakes and that's all I care about. I've also never seen it report something incorrectly or miss something important so it must be doing something that's nearly impossible.

Let me give you a concrete example. I have a gem's code loaded in rubymine right now and it has nothing to do with rails.

It has a module called "Foo" which has a bunch of methods.
It has a class called "Bar" which also has a bunch of methods.

Both of them are in different files. Now, I've required in Foo in Bar's file and mixed it into the class as usual.

Foo has 2 methods called: do_stuff and cool_stuff. do_stuff takes 0 args and cool_stuff takes 3 args.

When I try to use cool_stuff incorrectly by calling it with 1 argument instead 3 then rubymine squiggles it and tells me that it found the wrong number of arguments.

It does this because it indexed my code base and anything on my gem path really, so it can do this for arbitrary gems/third party code).

It also tells me where the method is being used else where, and I can jump to its implementation, etc.. It also has a nice little colored box in the gutter which tracks all warnings and errors. It even gives code style warnings which violate an unofficial but popular ruby coding standard (since ruby doesn't have anything like pep8).

I think you're mistakenly thinking that this is some kind of special class of errors that's easier to catch, but it's not. To catch this in every possible instance, it has to know the narrowest possible static type of every variable, at which point you're done with all type checking. I don't have the time to explain in detail how type inference can be done, but this is the general approach:

http://en.wikipedia.org/wiki/Unifica...puter_science)

With a few gotchas - full unification algorithm is really slow in the degenerate case and does not really work in languages like Ruby because variance issues. For example, if you have:

a = b

In normal unification algorithm, if b is of type X, it can logically constrain a to be of type X as well. But in Ruby, b is not just of type X, but of every class X inherits from including Object. Thus a cannot logically be constrained any further from this alone. In fact, just treating everything as an Object satisfies every constraint - it's just not strict enough. There are other approaches but they all involve searching through the constraint space as in unification. A more opportunistic algorithm will try to assume that a is X and see if everything can be unified, then gradually relax. But even a simple assignment (because assignment is covariant, see: http://en.wikipedia.org/wiki/Covaria...puter_science)) screws up complete type inference, whereas in languages without subtyping, all operations and functions are invariant, which allows for full unification.

In Ruby, there are a few things that have a meaningful static type - self, classes, modules, literals, lambdas and methods but by and large most Ruby constructs cannot be constrained except with type inference. And because there are a few show stoppers (covariance/contravariance), complete type inference simply isn't possible and we're mostly in the realm of guessing.

I don't have any experience with RubyMine, but not only is the problem theoretically intractable, the general state of the art in type inference for dynamic languages is quite poor (I do read these papers). This is why a lot of research is going into optional typing. So I think when you're saying it catches wrong method names and wrong # of arguments, you're probably saying that it can check if some method names are literally not used anywhere and thus cannot possibly apply to the given object. I'm sure it can in some limited cases, figure out the actual object type too. But this is extremely trivial and quite frankly almost never happens to me in any language even without any IDE assistance. And in a large codebase, lots of random wrong method names will be actual method names somewhere else, allowing you to proceed. What you do want to check is whether you have the right object in the first place and no, despite your protestations, this is virtually impossible in Ruby without huge amounts of annotations.

This is a trivial case because in this case, you have type declaration in the form of an include. Bar is a Foo and you've declared it. No type inference is required when language structurally forces you to declare it. Not even Java requires you to declare the type of this/self.

What's hard is when you're far afield from all this and you have an object that RubyMine can't figure out if it is a Foo or a Bar or anything.

It's ok, you don't have to explain anything.

I'll continue to use rubymine and have it catch every typo/argument mismatch error that I manage to fat finger and I'll continue being a happy customer. It might be guessing at a lot of it but it's damn good at guessing.

I'm not sure why you need to push your static language case so hard. Just accept that a lot of people are happily using dynamic languages and being very productive / working on projects that are considered successful.

Anyone have any good "real app" tutorials for iOS? I think I have a decent grasp on building a toy app, but would like to see something built beyond a 150 page book (i.e. the problem with every damn programming book).

Rubymotion seems to have pretty solid community support. http://rubymotion-wrappers.com/ I guess I could just look through some of the source code on various gems that do stuff I want.

I'm not pushing anything. I happily use dynamically typed languages myself quite productively and I don't have any problem with people using whatever. I'm just correcting incorrect statements about what type inference can get you and pointing out the contradiction - happily relying on other people's type annotations that are helping you prevent errors, while downplaying the importance of writing type annotations to help others prevent errors.

Btw, dynamically typed languages have some huge advantages:

1. Implementations are considerably simpler and more likely to be maintained or replaced in the long run.

2. As a corollary to 1, you're more likely to get multiple implementations and a more reasonable, common spec.

3. They are simpler and easier to learn relative to similarly expressive statically typed languages.

4. They tend not to attract the monadic priesthood (modern version of Lisp weenies) that gets nothing done beyond scaring away mainstream programmers.

5. It's easier for beginners to get a program to run.

6. Programs tend to be shorter, especially when it involves unconstrained interaction with the outside world, which is naturally dynamically typed.

7. It's much easier to bend the language in ways unintended or unanticipated by language creators, which is useful for many types of frameworks.

it's hard to overstate the value of this. i'd add that as a corollary (though this is not always true) a good dynamic language is more likely to minimize the gap between your mental model and the code itself. to take an extreme example, reading java feels like reading a manual on java syntax... i am always reading *java* and not what i want my code to do. in a well written ruby program it can feel almost as if i'm reading thoughts written down in english. this is not a static/dynamic dualism per se, but i feel like dynamic languages are more likely to fall into the "close to thought" category.

I completely agree with this. Another way to think about this is that static typing is an odd combination of low-level optimization hints and high-level declarative language for specifying program behavior. Now there's obviously logic in that madness but it just is not natural.

So 2 years ago today I hadn't written a line of code in anything since high school on a TI-85 and hadn't had a job of any sort in 8 years.

Today I accepted a position with a title of "Senior Software Engineer" at a fortune 100 company.

#bootstrapz

Congrats! Do you mind sharing an outline of the path you took?

After poker I pretty much said "what could a guy with no degree and no experience do that doesn't suck?" and yeah figured I'd try webdev. I like "design" and UI/UX so stuck with the front end. After a few months of study, writing things, and throwing some stuff on github I managed to stumble into doing some work for a couple local businesses which was enough to get on a resume/give me something to talk about. From there I built a pretty complicated flashy portfolio site that showed some stuff that wasn't terrible. Added a couple years of "freelance and contract" webdev to my resume, posted it online, somehow got through an interview for a 3 month contract, went from there.

And as processor architectures evolve I would expect these languages to become "closer to the machine" than they are now.

Too cool.

First, that's awesome. Congratulations.

Second, I wish I could find a good blog post I read recently about how our profession has a poor grasp of what "senior engineer" should mean. I found it really useful in thinking about how to keep growing in the field in ways beyond basic technical skills. I'll try to find it and postit when I'm back to my computer.

Edit: http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/

you disgusting unethical pig

congrats!

Not following this - what does this have to do with processor architectures evolving? Generally new CPU features and more complex CPU architectures increase the gap between low-level and high-level languages in terms of performance. I guess if you're saying since everything's getting fast enough, performance matters less, I agree of course.

What's going to help dynamic languages perform faster is improvements in compilers, but there haven't really been much of a knowledge breakthrough since the 90's. At this point most of the challenges are in making appropriate trade-offs and managing the staggering complexity that's inherent in applying a long list of optimizations. Don't forget that we had very fast Common Lisp and scheme implementations way back in the 90's and 00's.

I'm guessing that the main reasons that Ruby and Python are so slow are that they have some language features that are inherently optimization-unfriendly (possibly including current C module interface) and that the best people are all working on Javascript/Java/C#/C++ for big bucks or statically typed functional languages for research. To learn to optimize dynamically typed languages, you have to understand the nature of (static) types (as program invariants) at a deep, deep level and people with that background are too enamored with static types to be interested in Ruby and Python.