Go away, or I shall taunt you a second time!

Cyrus Blather Go away or I shall taunt you a second time | fire pit

Cyrus Blather Go away or I shall taunt you a second time | fire pit — Fri, 19 Jun 2009 08:58:44 GMT

PingBack from http://firepitidea.info/story.php?id=13

Cyrus Blather Go away or I shall taunt you a second time | low cost car insurance

Wed, 17 Jun 2009 07:29:11 GMT

PingBack from http://lowcostcarinsurances.info/story.php?id=6933

Cyrus Blather Go away or I shall taunt you a second time | Paid Surveys

Cyrus Blather Go away or I shall taunt you a second time | Paid Surveys — Fri, 29 May 2009 23:16:39 GMT

PingBack from http://paidsurveyshub.info/story.php?title=cyrus-blather-go-away-or-i-shall-taunt-you-a-second-time

Website Scripts » Cyrus’ Blather : Go away or I shall taunt you a second time!

Website Scripts » Cyrus’ Blather : Go away or I shall taunt you a second time! — Sat, 26 Jan 2008 07:52:19 GMT

PingBack from http://websitescripts.247blogging.info/cyrus-blather-go-away-or-i-shall-taunt-you-a-second-time/

smile

Best — Fri, 02 Sep 2005 19:44:50 GMT

Interesting info

re: Go away, or I shall taunt you a second time!

Darren Oakey — Thu, 08 Jul 2004 03:12:00 GMT

Cyrus
This was an interesting question - I used to _LOVE_ VB... In those days I'd be coding mostly in VB with a little C++ backing me up...
I'll start with a caveat that EVERYTHING I liked about VB was destroyed with VB.Net - I wouldn't touch it with a barge pole - C# is just... better.
However - everything I miss about VB comes down to two concepts - boundaries and readability.

boundaries: I think people always lose sight of the fact that more boundaries = faster development. Sure, sometimes there were things you had to "work around" - but when it came down to it, if there is just "one way" to do something - then that's how you do it. Look at the C++ world, where it's quite common to have developers go off on just a complete tangent to produce a"beatiful" template structure, when an ugly hack would have done the job fine.. People have to realise - increased "Flexibility" ALMOST ALWAYS _decreases_ productivity (but of course might have other good effects - increased quality/ robustness/ elegance/ maintainability or something).

readability: to me, as I always say, code readability is the single most important constraint when coding. Nothing else comes even close. And I define code readability as "how long would it take someone who has never seen a computer before to understand this function" - I do NOT accept the argument that code should be written to be clear to an expert in the language - I want code to be just written _clearly_ - not "clearly if you understand all of this to begin with".

So - specifically, what I miss about VB? (in order)

-- compilation speed --

I used the compiler as a task list - I'd write a test and make stubs with garbage like "asdfasdfjash" - hit f5, start coding out what I'm doing, get halfway through a line, realise I need a helper function, go code that, maybe repeated two or three levels down - hit f5, continue from where I was at, hit f5 fill in something else as well. It told me what I was doing, where I was up to, and that what I've done so far was ok. I still code like that, but just FAR FAR more slowly.

-- my error handling libraries --

My roll-your-own exception handler library gave me the values of the parameters in a function. Because I think and program largely functionally, this meant that in the case of an error, I basically had the entire relevant state of the system sitting in front of me - debugging was rarely necessary - even production bugs were trivial to track down and fix, because you didn't first have to reproduce the problem.

-- binary compatibility --
you could actually safely give out code libraries, and have reasonable confidence that you aren't going to break anything when you give out the next version of your library.

-- predictable garbage collection --
I liked the VB garbage collector and hate the .NET one. I know how I code. I NEVER EVER have a bidirectional link between two classes, (except through the observer pattern) - so a reference counted solution suits me fine. I am quite comfortable I'll never code a memory leak... However, I do like the fact that things go away at predictable times.
I know dispose exists (and I use it heavily, I can tell you) - but I would just like EVERY class to "require" a dispose, and dispose to automatically be called when they go out of scope :)
We have had so many GC related errors. Lots to do with forgetting disposes of course when people did things like open connections, but we've stamped a lot of them out - but more because the GC isn't even vaguely as active as I'd like it to be - .NET programs are memory pigs. For instance, we had a problem with our build server where we noticed it was slowing down all day - a build in the morning was 20 minutes, but by the evening it was up to 1 hr. We narrowed the problem down to the web tests. I put the words GC.Collect() - GC.WaitForFinalizers() into the load of the master page - the initial build went up to about 21minutes, and NEVER slowed down again...

-- no brackets on subs or empty functions --
I liked seeing code like:
> foreach employeeToNotify in theListOfLateEmployees
> NotifyThe employeeToNotify

-- only interface inheritance --
generally, I think inheritance is the single most badly used, over used, least understood concept in programming. I LOVED the fact that VB gave you all the benefits of inheritance with none of the disadvantages, by forcing you to always to an interface based inheritance

-- english operators and/or vs & | --
> if theEmployee.IsValid andAlso theEmployee.HasBeenChanged then Save theEmployee
is so much more readable than
> if (theEmployee.IsValid() && theEmployee.HasBeenChanged()) Save( theEmployee);
one looks like code, the other looks like english...

-- no visible plumbing --
with vb, if you dropped a control on a form - you didn't see the control definition, you didn't see code setting it up, you couldn't break it, you couldn't meddle with it. increased robustness + increased readability - good stuff

-- "with" --
while I would _never_ nest a with block, I thought with was a very elegant syntax - especially for doing things like populating a set of controls from an object, or vice versa
> with theEmployeeToDisplay
> NameDisplay.Text = .Name;
> PhoneDisplay.Text = .Phone;
> BirthDateDisplay.Date = .Birthdate;
> end with

-- case insensitivity --
(although I wouldn't change it about c# - they are different languages)
- but I used to USE case insensitivity as a tool - I would ALWAYS type in an INVALID case - when I moved to the next symbol I always knew if I'd got stuff right, because the symbol would change - sounds silly, but it improved my productivity.

(note - I've ignored all the common ones, like e&c - because you all know them already)
Mind you - I'm not coding in VB, so I can't miss'm all that much :)

re: Go away, or I shall taunt you a second time!

Cyrus Najmabadi — Sat, 03 Jul 2004 21:09:00 GMT

Kavan: C++ has memory management. C++ even has automatic memory management. C++ even has automatic garbage collection as well :-)

What other features did it lack?

You're absolutely right that each feature you add also adds complexity and friction. This is why we usually won't add something to the language if there is the equivalent way to do it that is relatively as easy.

This is something we would be worried about with strict/nonstrict. Would it have to be something you declared in the code? If so, then it adds clutter to the language. If you didn't have to declare it in the code, but instead set a compiler option, then suddenly when someone comes and looks at that code then they could get very confused when wondering how it is that your code even works.

A possible option is to extend the unsafe context to embody what you are asking for. So in unsafe contexts you could not initialize variables, or you could not return a result through all code paths even when required, etc. That would sort of follow the meaning of "unsafe". i.e. "i'm going to do things that the compiler can't verify and I'm going to take responsibility for that myself." It's something I'll propose.

re: Go away, or I shall taunt you a second time!

Cyrus Najmabadi — Sat, 03 Jul 2004 21:03:00 GMT

John: I like your analogy. :)

However, one thing we've noticed in Omaha and Mi is the higher rate of speeding and crashes vs. the rest of the country :-)

Given our lack of time to support what both sides want, we went with safety first. Again, something that most of our customers were asking for.

re: Go away, or I shall taunt you a second time!

Kavan — Sat, 03 Jul 2004 15:43:00 GMT

John: I completely agree with what you're saying. The idea is not to throw away auto breaking, but to make it optional. Depending on what you're doing you need different amount of friction. When I'm developing class libraries I always use option strict on. When I get to the highest level of programming, scripting, I turn it off. That's why users like Fuzu don't like C#. It's not suitable for that kind of job. There is always a compromise between development time and long term maintainability. You as developer know the lifetime of the project. If what you're doing is just a prototype you don't want all the development speed you can get. And having automatic breaks doesn't help here.

In a broader picture I see that C# language is evolving in a way that when feature can be useful but can be misused, it gets discarded. If some developers are stupid it's better to take it away from everyone. I'm more for the idea that developer should get an option to decide what's useful to him. There will always be bad developers, you can't change that. You might say that this was the case with C++. That's not true, it lacked important features like memory management and many others. Another thing is that sometimes including a feature would have impact on complexity of the whole language. That's what happened to C++.NET compared to C# and VB.NET. All the clutter of managed extensions gives you just as much friction as explicit casting.

re: Go away, or I shall taunt you a second time!

John Cavnar-Johnson — Sat, 03 Jul 2004 14:43:00 GMT

Cyrus,

The danger of static typing is the cost it imposes on the developer. John Lam described it (see above) as friction and I think that's an appropriate term. Friction slows things down and that's not always a bad thing. Think about driving a car. You use friction (your brakes) to slow the car. The C# approach is similar to a car that is designed to automatically apply the brakes every time you change direction, based on the degree of change. If you learned to drive a car like that, you would be horrified at the thought of a car that didn't apply the brakes every time (my gosh, the driver would have to remember to do it on their own without any help from the car). The problem with that system would be that it applies the same amount of friction under all driving conditions. It's unsafe to drive on snow or ice. If you lived in San Diego, you would have a hard time figuring out why the folks in Omaha and Minneapolis didn't like that design. Developers at Microsoft pretty much live in San Diego (metaphorically speaking). Static typing rarely imposes an unnecesary burden on them. A lot of your customers live in Omaha or Minneapolis.