4 ms·

No, there's a huge difference in quality of programmers. I've led a team that was productive (by which I mean shipping code that met business goals) within wee

by kod 10y ago

No, there's a huge difference in quality of programmers. I've led a team that was productive (by which I mean shipping code that met business goals) within weeks of starting with scala. I've been on other teams where some of the guys still couldn't understand closures after 6 months.

codygman 10y ago
That sounds less to do with quality and more to do with exposure to the functional paradigm.
geoka9 10y ago
> I've led a team that was productive (by which I mean shipping code that met business goals) within weeks of starting with scala. Personally, I like to measure things like that by how fast a team/developer can get up to speed on maintaining an already existing non-trivial codebase in the language. Shipping greenfield projects is often easier than adding features to an existing one, particularly in languages like Scala.
- runT1ME 10y ago
  Shipping greenfield projects is often easier than adding features to an existing one, particularly in languages like Scala. I don't agree. I work on an incredibly large Scala team and a powerful type system gives you a lot more confidence to make everything from minor bug fixes to sweeping refactors. The price paid for having to learn the complexities and power of Scala (which I'll admit is much harder than other languages) pays off in that it lowers the overall application complexity by reducing the need for a plethora of frameworks/libraries. If you write Scala like you'd write a java/python/Go application, you'll have better type inference and a worse IDE, along with slower compile times. Not a great proposition. If you write Scala like a pure functional language that allows you to create powerful libraries and DSLs that make it possible to hack together very reliable applications, you'll be amazed.
- kelnos 10y ago
  I don't think I'd agree with that. I tend to learn languages by looking at what others have done. Doing something from scratch in a new language with unfamiliar libraries is really hard. Digging into someone else's codebase -- assuming they've done a good job at writing clean code and avoiding being "clever" -- to make small changes is way easier when you're first starting out.

by kod 10y ago

codygman 10y ago

That sounds less to do with quality and more to do with exposure to the functional paradigm.

geoka9 10y ago

> I've led a team that was productive (by which I mean shipping code that met business goals) within weeks of starting with scala. Personally, I like to measure things like that by how fast a team/developer can get up to speed on maintaining an already existing non-trivial codebase in the language. Shipping greenfield projects is often easier than adding features to an existing one, particularly in languages like Scala.

runT1ME 10y ago
Shipping greenfield projects is often easier than adding features to an existing one, particularly in languages like Scala. I don't agree. I work on an incredibly large Scala team and a powerful type system gives you a lot more confidence to make everything from minor bug fixes to sweeping refactors. The price paid for having to learn the complexities and power of Scala (which I'll admit is much harder than other languages) pays off in that it lowers the overall application complexity by reducing the need for a plethora of frameworks/libraries. If you write Scala like you'd write a java/python/Go application, you'll have better type inference and a worse IDE, along with slower compile times. Not a great proposition. If you write Scala like a pure functional language that allows you to create powerful libraries and DSLs that make it possible to hack together very reliable applications, you'll be amazed.
kelnos 10y ago
I don't think I'd agree with that. I tend to learn languages by looking at what others have done. Doing something from scratch in a new language with unfamiliar libraries is really hard. Digging into someone else's codebase -- assuming they've done a good job at writing clean code and avoiding being "clever" -- to make small changes is way easier when you're first starting out.