1 hour ago, cbae wrote
@JoshRoss: IIRC, Bass even stated that he thinks comments in source code to be unnecessary.
I know that he doesn't comment his code, but I would think he would comment his check-ins.
Loading User Information from Channel 9
Something went wrong getting user information from Channel 9
Loading User Information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
1 hour ago, cbae wrote
@JoshRoss: IIRC, Bass even stated that he thinks comments in source code to be unnecessary.
I know that he doesn't comment his code, but I would think he would comment his check-ins.
@cbae:
You got me.
@JoshRoss:
Pre-commit hooks can force comments that aren't an empty string.
But now that you made me think about it, this process deserves scrutiny. If I add "i = 7" and commit comment "assigned 9 to i", I'm pretty sure every version control in existence will gladly accept this clear deception. That is a bug, and a dangerous one at that.
@Bass:
You really say comments are unnecessary or you were joking? Just want to double check.
Pre-commit hooks can force comments that aren't an empty string.
But now that you made me think about it, this process deserves scrutiny. If I add "i = 7" and commit comment "assigned 9 to i", I'm pretty sure every version control in existence will gladly accept this clear deception. That is a bug, and a dangerous one at that.
That's not a bug, it's a reason to fire a bad programmer.
I don't like the philosophy behind commenting code. It seems to imply that the code itself isn't understandable. And that is the fundamental problem.
Either:
IMO, this is in order of commonality. All these are some kind of failure. Comments thus are a crutch for some kind of deeper failure in the code, organization doing the commenting, or programming language.
If comments were docile, I'd let it pass. But from the perspective of the machine, they aren't falsifiable. So:
I feel that adding the ability to comment code is up there with the "null" type in the fail department of programming languages, ie. one of the worst ideas to ever grace the programming profession.
Unfortunately, because comments are so easy to add to programming languages, they will continue on forever I'm sure.
@Bass: So you have never had a situation where you've gone "this is a really clever but complex solution to a difficult problem, I'd better add a line of text to explain it"?
Or even "this is a really ugly hack but it's necessary, better explain why I did it lest this code end up on thedailywtf"?
Comments that explain what you are doing are bad, for reasons you say (except in documentation comments since as the consumer of a method I don't want to have to read the code). But comments that explain why you are doing something are absolutely indispensable. And if your algorithm is complex enough, I'd rather read a few lines of text (with the possibility that they might be stale or wrong) than weed through 1000s of lines of codes in the hopes of figuring it out.
10 hours ago, fanbaby wrote
Just to add to my post, open source is great isn't it? We live in a great time. OS is the great equalizer. How else can a single guy create something, say jQuery or CoffeeScript, which decimates other work by large teams, whether open or close.
So today Microsoft added yet ANOTHER transpiler. Great. News at 9. You see, in this new world, the fact that it's Microsoft, or Google, or Apple or anyone, means nothing.
Well said - though you might be surprised at how many important projects at Microsoft are the responsibility, code-wise, of basically one developer or a small team ... ![]()
@Bass: Code that is self-evident with respect to what it does isn't necessarily self-evident with respect to WHY it was done a particular way. Programming is about choices, and you sometimes have to explain why you took a particular choice over another. I personally don't comment my code much, but this is one of the few reasons for which I comment even when I'm the only one to read the comment.
As for nulls, they're not usually types per se. They simply add to the range of possible values for a given type. I find the concept useful.
OTOH, I think the difference between == and === operators is one of the most retarded concepts ever invented.
24 minutes ago, Bass wrote
I don't like the philosophy behind commenting code. It seems to imply that the code itself isn't understandable. And that is the fundamental problem.
Either:
- The author can't write understandable code.
- The reader isn't qualified enough to understand the code, and shouldn't be let anywhere near it .. comments or not.
- The language isn't expressive enough.
IMO, this is in order of commonality. All these are some kind of failure. Comments thus are a crutch for some kind of deeper failure in the code, organization doing the commenting, or programming language.
If comments were docile, I'd let it pass. But from the perspective of the machine, they aren't falsifiable. So:
- They can outright lie (maliciously even.. only code can be trusted) or get stale or just wrong over time.
- They can't be proven correct (see: unit tests for an informal but pretty effective way of testing the functionality of code, AFAIK no equivalent exists for comments).
I feel that adding the ability to comment code is up there with the "null" type in the fail department of programming languages, ie. one of the worst ideas to ever grace the programming profession.
Unfortunately, because comments are so easy to add to programming languages, they will continue on forever I'm sure.
I agree with the principle, but I think you are taking things too far.
Just to make an example, the readability of any piece of code is strongly correlated to how meaningful are the identifiers the programmer chose. Yet, identifers are just as unverifiable and potentially misleading as comments.
If anything, yours are excellent arguments for the introduction of optional type annotations as they make it easier for programmers to express the intent of the code, when needed, and provide some implicit verifiability.
In case you haven't looked through the questions on stackoverflow, here is your chance. Some of these questions, and some of these answers, are pretty good.
-Josh
10 hours ago, AndyC wrote
*snip*
LOL, only in fanboy dreams. FOSS projects without substantial backing are high risk options and always will be. Nobody wants to bet heavily on something that disappears overnight because the kid responsible for it got a real job/bored/went to college etc.
While it's true there are risks for using FOSS stuff Microsoft has left people high and dry too.
I used to think Microsoft was in it for the long game but it's pretty clear with what they did with WP7 and WPF/SL and now their replacement that locks you into W8 that it's "use at your own risk". There is no difference in Microsoft "supporting" a deprecated language, API, etc. or a FOSS project that goes dark. You can still use both stacks they're just not going anywhere. At least if you're desperate for a fix in a FOSS project you can get the source and fix it yourself.
That said I do give Microsoft credit for embracing FOSS stuff like node.js, jquery, etc. It helps balance things out a bit.
@DeathByVisualStudio: And Windows Mobile, but that was junk. But, if they were any good, people would still be using them. These tools are like sharks, if they aren't moving forwards, then they are dead.
-Josh
31 minutes ago, JoshRoss wrote
@DeathByVisualStudio: And Windows Mobile, but that was junk. But, if they were any good, people would still be using them. These tools are like sharks, if they aren't moving forwards, then they are dead.
-Josh
No argument there; just that Microsoft is no better. And they have that nagging thing called a profit motive hanging over their heads...
@DeathByVisualStudio: At this point, I would say that Microsoft is doing FOSS better than the other companies who present themselves as champions of FOSS.
2 hours ago, Bass wrote
I don't like the philosophy behind commenting code. It seems to imply that the code itself isn't understandable. And that is the fundamental problem.
So you are a mind reader aren't you. You can predict perfectly what the intent of the previous programmer's design decisions by just looking at its code.
Sometimes you see code that doesn't do exactly what you would expect, but, for good reasons. If they don't leave a comment to why they decided to implement this way, you would just think they are nuts.
12 minutes ago, kettch wrote
@DeathByVisualStudio: At this point, I would say that Microsoft is doing FOSS better than the other companies who present themselves as champions of FOSS.
Really? How so? Just curious.
@DeathByVisualStudio: They are the most upfront about what they are doing. Companies like Google and Apple seem to be hiding behind the FOSS banner and using it for their own purposes, but don't seem to give back as much as they take.
Microsoft doesn't use any FOSS in their products, but gives a whole lot to the community. They aren't even pushing their own branded licenses any more and are instead using licenses that are more palatable to the FOSS fanbois.
It has been done before and arguably better. We've been using CoffeeScript for some time, it's a good example of a language that improves JavaScript significantly while not being some kind of totally different idea or doing silly things like adding static typing.
Well, just because it's been done before is no reason not to try to make it better. And what's wrong with static type checking? Won't that mean less errors (especially for inexperienced programmers) and more speed?
This is a worthy effort though from first looks I prefer Kotlin.
Add your 2¢