If you asked me 6 months ago I would say the features that confused me the most:
- Covariance / Contravariance
- Implicit Parameters
- Implicit Conversions
- and also mentioned here, Structural typing.
However now that i've spent time with the language, seen these in action and used them myself I see the reason why they exist and embrace them. I can see why this would be a common complaint against Scala and can be a barrier for a lot, but I think the language is worth investing time in learning, at least for me.
Covariance / Contravariance - Noooooooo!
I admit - this might be hard to grasp at first, but in reality it is very simple concept that simplifies a lot of code. It is enough to get variance right once for a class, instead of fighting with ? in Java everywhere.
BTW: Kotlin has copied it and noone complains it is too complex :D
As of implicit parameters / implicit objects - ok, but what do you suggest as a replacement so that map/filter/reduce preserve types correctly? Or how do you do type-classes then?
"As of implicit parameters / implicit objects - ok, but what do you suggest as a replacement so that map/filter/reduce preserve types correctly? Or how do you do type-classes then?"
I don't have a specific answer to this question, but I do want to warn you that this is a dangerous line of reasoning. Given a complicated object like Scala or C++, you can easily have a situation where each individual element is necessary to support two or three other elements of the overall structure, yet, the overall structure can still be too complicated.
And to be clear, I'm not even saying you're wrong. Maybe there isn't a better choice. Scala's choice to be compatible with Java creates a very strange design situation. I'm just saying, this isn't a safe line of reasoning. I think it makes it very easy to become very short-sighted about your options by encouraging you to always be very locally focused.
Agreed, Covariance / Contravariance was a fantastic feature to borrow from C#! It just should have been implemented to be friendlier to people new to language.
Variance has been well understood in PL theory in basically forever. None of the languages had to borrow it from each other because they could all just get the inspiration from type theory.
Ehm... No. If any, C# borrowed it from Scala. C# got them in version 4.0, which was first half of 2010. Scala had them since I remember (from day 1?) - for sure they were in Scala 2.6, which was released in 2006.
And C# could only add it because the now-F# folks had originally designed it into the CLR Generics system. It's highly unlikely C# would ever go far out of the straightforward IL generation it does to implement such a feature otherwise.
Right, variance was part of the original MSR proposal for CLR Generics.
How did delegates use variance? I've never been terribly clear on the whole delegates concept - they're like first class functions, except nominally typed and weird.
Well done! This is definitely something I will come back to repeatedly. It's very complete, but at the same time not overbearing. The scaladoc feature is awesome, I wish my IDE could do this so well. Can you give a run down of the stack and how it all comes together?
The author, Manny Howard, was on the Colbert Report tonight. This guy was incredibly deadpan, one of the more enjoyable Colbert guests that I can remember.
That's what prompted me to look him up. I caught parts of the interview while browsing the web, and decided that he sounded interesting enough to warrant a quick search, and this article turned out to be better than the interview (at least from an information perspective).
I started programming as a young man on Visual Studio programming in VB and C++. There came a day years ago where I had to work with a text editor and a terminal on an AIX system and was surprised at how little I knew in terms of compiling, building, and programming in general (how is a class structured again? What packages/headers do I need to reference? What directories do my files have to be in? Why isn't my code running?). I think it's important that those who code exclusively in IDEs step back every now and then and understand how these 'auto-magic' functions IDEs provide work. I've now spent years using IDEs in addition to my own custom environment (I switch back and forth between vi, gedit, and textmate (when i'm on a mac) and make extensive use of sed/awk and other CLI commands to do custom activities that IDEs certainly cannot provide).
IDEs bring a lot to the table, but I can't help but agree with you in that it can be a horrible experience, especially to those who are accustomed to having complete control over everything in their environment. I think it's great for getting things done efficiently, but developing exclusively with them can bring a close-minded view of how things work.
You read the article I linked to, right? I can hardly disagree. Nevertheless, after writing code that way for so long and being a very zealous old-school UNIX guy, I guess I'm interested in trying a newer, more conventional way of doing things.
'more convenient' often means far more trouble in the long run.
I've seen colleagues use their IDE build process which is completely broken, and spend a day trying to figure out what's wrong... (Never use a build process in an IDE).
You see people blindly creating source files that are thousands of lines long and not noticing since their IDE folds the code etc. The IDE hides the bloat. Which is a terrible thing.
When you start trying to integrate svn, build process, etc into an IDE, everything goes wrong.
The 'intelligence' in textmate was even too much for me. Inserting "" when I pressed it once, trying to do code indenting. It still drives me mad how it handles tab and spaces (When I press delete, I want it to remove one space. Not 4).
I really don't think an IDE is 'more conventional'. Perhaps in corporate cubeville.
I guess I avoid some of these pitfalls because I wrote C and Perl with vi for 10 years, and used a relatively spartan FVWM environment consisting solely of terminals and command-line approaches to all problems.
That method of approaching programming and technical work isn't going to change for me even if I forklift-upgrade my Java text editor to something a little fancier, which is essentially what I see myself to have done here.
I can't use an integrated build process anyway because I'm working on a backend server process that necessarily must reside on a remote machine; there'd be virtually no point in trying to develop or run it locally, as it depends on connectivity to too many other resources for any aspect of its functionality. So, I mount the source directory over SSHFS or NFS and edit it "locally" with Eclipse, but the build process is remote and done via a manually crafted Ant build file.
I haven't seen Eclipse fold any code other than the big comment block at the top of every source file.
I wouldn't be opposed to integrating SVN awareness into it, but find it a bit problematic since I'm using SVN over SSH.
I don't know if these are techniques rather then hotkeys, but I actively use the following (Note: I'm not really a big fan of IDEs, but use them professionally to conform to my work environment and Eclipse, while somewhat bloated, is very pleasant and gets better with every milestone).
Debugging:
Learn the hotkeys for stepping in (F5) over (F6) out (F7) and continuing (F8), I get super frustrated watching people click on the icons. Really helped the transition from debugging with the likes of gdb.
Conditional Breakpoints are a revelation.
Remote Debugging is great (I've been able to debug remote java processes, Lotus Notes (yuck) instances, Eclipse workbenches (for plugin development), Remote Perl Server Code (with E-P-I-C and Padwalker)... Eclipse's debugger interface is amazing.
Text Editing w/ Java and CDT:
CTRL+W : close active editor
CTRL + Space : Autocomplete (mentioned earlier)
CTRL + SHIFT + O : Organize Imports (Finds classes that should be imported, removes excessive imports, etc...probably one of the most justifiable reasons to use an IDE for Java development)
ALT + SHIFT + J: Add Javadoc in context
CTRL + SHIFT + G : Does a search on the highlighted text's context (i.e.) a method name to show where it is used.
F3 : Navigates to selected context (Method, class, variable, etc.)
CTRL+SHIFT+T : Presents Dialog for searching through Types (works in most perspectives), i.e.: Searching for a particular java class.
F4: Show the Type Hierarchy (subclass/superclass information)
Import & Export wizards are your friend (Creating java jars, exporting projects to archived zips).
Eclipse can be used to track history (kind of like your own personal lazy SCM). If you make a mistake you can right click on a file and perform "Replace With > Local History..." (this may need to be enabled in preferences). You can also Compare to history well.
Tasks : The 'Mylyn' plugin is great for GTD and Task management. I was a bit apprehensive at first, but it's pretty incredible, especially if you are a nut about keeping organized. You can create tasks, and assign your current work to it, and it will track and remember context (what classes you used) as you work on that task. Mylyn also interfaces with Bug Trackers like Bugzilla and JIRA.
CTRL + SHIFT + O : Organize Imports (Finds classes that should be imported, removes excessive imports, etc...probably one of the most justifiable reasons to use an IDE for Java development)
- Covariance / Contravariance - Implicit Parameters - Implicit Conversions - and also mentioned here, Structural typing.
However now that i've spent time with the language, seen these in action and used them myself I see the reason why they exist and embrace them. I can see why this would be a common complaint against Scala and can be a barrier for a lot, but I think the language is worth investing time in learning, at least for me.