C# with visual studio is, I think, the most productive environment I've come across in programming. It's ergonomically sound, straightforward, and the IDE protects me from all sorts of relevant errors. Steve mentioned Intellij is a bit slower than he'd hope typing sometimes. I totally agree with that. I think Visual Studio doesn't quite suffer from that (though I haven't worked on huge projects, and that may well affect it). My main problems with IDEs are twofold: for non-static languages like Python, they're just not very good. Sometimes they do exactly what you need, and 70% of the time they're just totally useless (which is a knock on the programming languages more than the IDEs). The zippiness on reaction to my typing is another huge deal. If it's anything other than instantaneous, then I notice my editor in a negative light. When you pair a tremendous IDE with a good language though, the productivity loss of typing becomes pretty much negligible, and the gains for all the other reasons start to become apparent.
Changing one parameter or type on a class or function to refactor, and then just following the chain of compiler errors, reaching the end, and seeing that everything just works exactly how you want it to was a big eye opener to me.
Definitely going to give kotlin a go some time as well.
I definitely agree that dynamic typing doesn't scale as well as static typing, though.
Why not tests + static typing? Getting tests to point out breakages is attempting to do job the compiler can do for you but not as well. If you renamed a field in some places but not others for example, you'd have to rely on good enough code coverage to catch this plus deciphering a failing test is nowhere near as easy as a compiler error that pinpoints the exact line causing the problem. Tests take time to write and static typing is giving you many tests for free. You also miss out on automatic refactoring tools and autocomplete.
Wait, you don't enforce 100% coverage? (Sorry, couldn't resist ;))
I actually mostly agree, static typing is a huge boon for productivity, and certainly allows for less experienced (both new programmers, and new to the project) developers to become productive on a new codebase faster.
However, I think dynamic typing forces a certain familiarity with the codebase that can prove really useful. Yes, it slows learning down, yes it rules the lower end of the spectrum of developers out, but there are still benefits to this required familiarity.
Obviously, when codebases reach a certain size, this falls over. And even before they do, the drawbacks may be more than the benefits, but it's still something to consider.
My personal opinion right now is that these benefits don't exceed the drawbacks, that static languages are better, however I tend to flip flop back and forth on this every other month (or project).
Useful in what way? I don't see how static typing is going to make you less familiar with a codebase. Good use of types provides a certain amount of documentation for free as well.
I know this was a joke, but 100% coverage only means you've covered every code path, not that you've tested every case. Static types allow you to prove the absence of certain classes of errors. Of course, you still need tests for all of the classes of errors that your type system doesn't cover.
I made the mistake of trying to build a system in Powershell because the ability to remote into windows boxes was core to it. That was a mistake I didn't see coming.
* No automatic incremental compilation. It turns out, this feature is specific to Eclipse alone. In my current job I'm forced to use Intellij and cannot figure out for the life of me why people think Intellij is better. Automatic incremental compilation is a game changer and only Eclipse has it.
* Limited Code analysis and search. For instance checkout this SO: http://stackoverflow.com/questions/282377/visual-studio-how-.... This kind of symbolic analysis and code search feels essential to me in an IDE, and stock Visual studio just didn't seem to have it beyond the basics.
* Weak refactoring and code generation support. ReSharper might bridge the gap a little here, but stock Visual Studio felt way behind.
* Weak ecosystem for plugins and tool integration. With Java IDEs I have excellent integration with unit test frameworks, code coverage tools, checkstyle, my command-line build tool, etc. I remember it taking a fair bit of effort just to be able to run NUnit tests in Visual Studio. Why NUnit? Well, our software needed to build on Linux with Mono so we needed to use a cross-platform unit testing framework instead of the one built into visual studio.
As a side note, I think the plugins ecosystem is another area where Eclipse has an edge over Intellij. For instance, when I tried Intellij's code coverage tool I eventually gave up on it because it had a critical bug I couldn't diagnose that resulted in incorrect code coverage being displayed.
...and in Maven since 1.1.2: https://blog.jetbrains.com/kotlin/2017/04/kotlin-1-1-2-is-ou...
There's always been codegen support with snippets, although I never found too much need for it, personally.
The tools ecosystem is pretty weak though. I always found TestDriven.NET to be the best test runner, although Resharper's is OK if slow. I actually like NUnit a lot better than JUnit, but YMMV.
I thought that but PyCharm scores way better than 70%. I even trust it to do automatic refactors. Sometimes...
> The zippiness on reaction to my typing is another huge deal. If it's anything other than instantaneous, then I notice my editor in a negative light.
Maybe I grew up on IDE's but I type stuff in full only if autocomplete fails me. Maybe I have an appalling memory. Or maybe I'm really slow at typing. Or maybe my variable and method names are too short.
> I even trust it to do automatic refactors. Sometimes.
Function extract refactors and the like are definitely within the realm of possibility. Once you want to refactor code across many files it becomes a lot harder in dynamically typed code, for sure.
I guess for a long time I sort of had this view of "ooh I have this awesome expressive language that won't get in my way and I can just power through it all". Don't get me wrong, I totally love python as a language. But I think languages like C# have started to make typing feel like it's more out of your way with type inference, etc.
I mean, this is the sort of code you can write in C# these days (to take a super trivial example):
var somestuff = someList.Where(x => x.Id > 7)
.Select(x => x.Name)
var somestuff = from x in someList
where x.Id > 7
var somestuff = from x in someList
where x.Id > 7
var somestuffList = somestuff.ToList();
One of my hobby projects is in C, and I prefer using an editor to an IDE. Because of an accident of history, public methods tend to be named like `P_PlayerCommandRead`, where `P` means (generally) "physics", and `Player` and `Command` are essentially nested namespaces. I specifically name things this way so that I can type them quickly without spending a lot of brain cycles on figuring out the scopes.
I'm not saying code bases built with IDEs don't have consistent naming, or that code bases built without IDEs have hellish homegrown naming. But it's kind of a "how you grew up" thing, and it latches onto a lot of underlying feelings you have about coding in general.
C++ also often had that (replacing 'map' through 'transform' and so on) - but since it's a standard, at least it is usually more consistent in its own internal logic. Same goes e.g. for LINQ, which was influenced by SQL instead of LISP-like collection transformation functions.
This was an explicit decision to make functional programming more palatable to mainstream developers.
Have you read the paper from Erik Meijer?
But still - if you're used to the functional "default" naming schema (which mostly comes from math, anyway), it's nontheless something that can be a bit irritating (especially since there's also the "inline SQL syntax" you could use alternatively).
I cringe when I have to deal with one big legacy product of ours that still hasn't been converted from a Eclipse project to IntelliJ; it's an order of magnitude more painful to work with.
See, that makes a lot of sense on the surface... And I find it playing out across a lot of the modern IDEs like PyCharm...
But I don't think it actually has to be that way.
DrRacket blew most of what I knew out of the water. It could refactor for me, trace functions and calls to definitions through multiple libraries, which included argument arities. I could write code in the REPL and push it back up into the editor, or vice versa.
Not to mention that toying with another language is not such a complicated endeavor once you're 5-10 languages in. The great thing about C# and Kotlin is they've been good at adopting features from other languages that are already good and familiar, so picking them up is generally super easy.
.NET Core is awesome, but don't forget that it's not the first time .NET has been available to Linux developers.
Yup. Because they can't.
Without type annotations, IDE's are pretty much incapable of offering automated refactorings without human supervision (and yes, that includes Smalltalk IDE's).
They can give you some primitive auto completion and navigation, but that's pretty much it.
Actually they can.
> incapable of offering automated refactorings without human supervision
> (and yes, that includes Smalltalk IDE's)
Patently false. Everyone repeat after me: automated refactoring was invented on Smalltalk with the Refactoring Browser. Again. Automated refactoring was invented on Smalltalk with the Refactoring Browser.
The lack of static type information was considered a major potential problem by the authors when they started the project. They later reported how they were surprised when it turned out it wasn't.
So please stop spreading misinformation.
'This is absolutely the greatest piece of programming software to come out since the original Smalltalk browser. It completely changes the way you think about programming. All those niggling little "well, I should change this name but..." thoughts go away, because you just change the name because there is always a single menu item to just change the name.
When I started using it, I spent about two hours refactoring at my old pace. I would do a refactoring, then just kind of stare off into space for the five minutes it would have taken me to do the refactoring by hand, then do another, stare into space again. After a while, I caught myself and realized that I had to learn to think BiggerRefactoringThoughts, and think them faster. Now I use probably half and half refactoring and entering new code, all at the same speed (I should instrument to measure this). -- KentBeck'
Furthermore, the reason Smalltalk pulled all this off is because it is/was metadata-heavy. Every object could be interrogated about its shape and capabilities (in the form of asking about its "slots"), even though there were no static type annotations. It's sorta like the runtime-typing stuff done by Dialyzer in the Erlang/Elixir world nowadays, and the tooling and code all ran together in the same runtime/VM instance.
So no, a language without static typing or metadata is not as tooling-friendly as a language with such requisite available analyzable information, and certain categories of refactoring cannot confidently be done automatically.
This inspection capability has nothing to do with static/dynamic typing.
> So no, a language without static typing or metadata is not as tooling-friendly as a language with such requisite available analyzable information, and certain categories of refactoring cannot confidently be done automatically.
Yes, they are. You can do anything with IDEA/Eclipse + Java that you could do in Smalltalk + IDE.
> Patently false.
It's a mathematical fact.
Without type annotations, refactorings are never safe and need supervision from a human.
Did you notice that the "Refactoring Browser" calls itself just that, not "Automatic"?
Because it can't provide that guarantee. Even renaming a function is dangerous and can break a program when you don't have type annotations.
I have a lot of respect for Smalltalk and the pioneering work it accomplished, but the refactoring browser was just a powerful string replacement engine, nothing more. Which is not a knock on the engineers and scientists who invented it: it simply, mathematically, could not do more than that.
There is a difference between "I can prove this is safe" and
"this is safe". You guys need to start figuring out the difference between theory and practice.
No, it really can't, not with the correctness guarantees of a statically typed language.
If you are required to run tests to do refactoring, you're simply not on the same level.
The last paragraphs in this link for an example (Ironic title, I know. :) ):
Smalltalk authors seeing static typing as major potential problem when started years ago does not make it actual problem today.
> Smalltalk authors seeing static typing as major potential problem
Authors saw lack of static typing as a major potential problem. It just wasn't. Again: reading helps. A lot.
Even then you still need manual supervision in that it may work in 99% of the cases, but for a particular method it is more difficult to automate (because it's meaning is more overloaded).
And of course just because the authors foresaw problems and decided that it was fine doesn't mean someone used to refactoring in static type system can't have more stringent norms.
You also argue with hypotheticals (may...depend, likely be the case etc.). Why is that so? Is it because you can't accept that reality doesn't conform to your theory?
Once again: the argument was "you can't". That is as patently false as can be, in reality is it not just "you most definitely can", but "this system is extremely well suited for building this type of tool and in fact the whole category was invented on that system".
And your theoretical concerns notwithstanding, people who have actually used the system consider it best-of-breed.
A scientific approach adapts theory to observation. Theology adapts observation to theory.
Partly because my experience with Smalltalk has always been that my experience is less positive than what others claim to encounter (this is not just about refactoring, where at least once I wanted to rename a method, but this method name was also used in a different context where it shouldn't be renamed, typing would have made this irrelevant; but also about things like Monticello where I got far more conflicts and things that didn't work out of the box than I consider reasonable or knew how to handle). This may have been the way I got introduced to the platform, but it colors my skepticism about the generality of the observations.
> if my examples are good examples of showcasing the automated refactoring problem
More to the point: Smalltalk is as dynamic a language as practically possible and was like that for two decades before Python existed. The `__getattr__` from Python, `method_missing` from Ruby, and `__index` from Lua are all inspired by Smalltalk's `doesNotUnderstand`. The concepts of metaclasses and first-class message sends was invented in Smalltalk. The idea of inspecting code using a GUI instead of flat text files also originates with Smalltalk. Refactoring, as noted by GP, also came out of Smalltalk-land. Smalltalk gives you all that without any static typing in sight.
How? Smalltalk is special. Normally, you have your code: a static blueprint of what's going to happen; and a program: part of computer memory which your code gets loaded into and gets executed. This is true for both statically and dynamically typed languages: the familiar type something -> hit "Run" -> see if it worked cycle works equally well in Java and in Python.
Smalltalk is not like this. With Smalltalk, all you have is a program. It's always running. You hand it the code and it patches itself dynamically in memory. The classes are live objects you can query. Metaclasses are, too, objects you can query. They implement methods for refactoring. It's easy, because there's no need for any parsing, statical analysis of any kind: you just iterate over all the classes in your system and ask them one by one: "do you call such-and-such method?" And the classes inspect themselves and say: "why, yes, I call it when handling such-and-such messages, here's the list".
Really, Smalltalk is special. It's not unique: Forth and Common Lisp come to mind, Self, Lua and Io too. But it's special and very few modern languages come close to its capabilities.
Very specifically was: "(and yes, that includes Smalltalk IDE's)"