MalibuJack

iTrader: (5)

If you need something in VB.NET I'll send you the source code of the early version of Mitsulogger 1.0 I know what you intend to do with it, and I have no problem with the code forking for that purpose. PM me on aktivematrix.

The one thing I hate about VB.NET is how difficult it is to get it compiled to native code, I do like VB.NET because its more similar to C# which makes transitioning for me alot easier.

I have been programming in VB for a long time, I always hated the Runtime, and I see .NET as the same type of crap, but its the language I'm most proficient in and makes it alot easier to quickly produce an app in my work environment where there is no time to learn and program at the same time. Earlier versions of VB COULD compile to native code (at least in VB5 and VB6), but it was IFFY about how it did it. It was clearly not optimized, and still clearly had dependencies on compoments you might have used (OCX files) that were not always able to be compiled into the runtime files.

VB.NET (or any .NET code) really does a nice job of allowing components to communicate with eachother without jumping through hooks, and take a modular approach to things. But this is the nature of using CLR code.

I do have tools that compile .NET CLR code to native binary code, but it has a few drawbacks, mainly its difficult to get the results to communicate with eachother very easily. This is much easier to do in C++ after you jump through a few hoops, but after you do its much better to work with.

I'm not going to devend VB.NET because even though I'm a proficient programmer in it, I don't particularly like how things "work" in it. But to say it VB.NET cannot do the same things any other tool that creates CLR code is just plain FALSE, everything available in one is available in all. If your compiling to a native binary, then its mostly true.

My all-time favorite development platform and language is Delphi, the code is easy to write, runtime code is small and fairly streamlined, components that you use can all be embedded into the binary code, along with all resources (this applies to C++ also, but I'm not a fan of C#) Newer versions of delphi can compile to CLR or Native code.

CLR Has a MAJOR advantage though, the code written will run on anything that has a proper implementation of the .NET framework (2.0 or 3.0) where native binaries might not in every case. Hence the reason why I'm FORBIDDEN from compiling to native binaries at work.

Performance is kinda iffy, Windows itself is so bloated that most of the time, performance issues are not .NET related. Machines are so fast these days that most of the simpler apps don't benefit from native binary, especially if what your doing is communication related where your at the mercy of your communication pipelines.

But .NET CLR code has one big drawback, it can be easily "Disassembled" back into source, its not as pretty as the original, but its still possible to "look under the hood" fairly easily. Then you have obfuscation tools which will make it harder to read and discourage most people from bothering, but this does slow the code down.

And is it just me, or do C programmers come across as arrogant and closed minded?

codgi

iTrader: (22)

There are some specific cases where this is true. C# allows you to use unmanaged code directly with the "unsafe" specification which VB.Net does not allow you to do. Now before you go and say it, VB.Net does allow you to interact with some unmanaged code with the use of IntPtr. But it only allows you to do relatively "safe pointer" manipulation. So even the IntPtr type in C# and in VB.Net are not even the same (in C# you can hang yourself with it if you like).

There are a couple other low level differences between the two...see if you can find the Microsoft Whitepaper on VB.Net vs C# where the actual people who work on it can expand on those differences a lot better than I can.

I should have put Delphi there last night as well, great language even though I haven't touched it in 7 years now .

On the "you can get back the source code". That's the risk of using any IL type language. You can do the same thing with Java. It might not revert as "Cleanly" as a CLR language. But if I am determined enough I don't need to have the exact line by line code to figure out how your program does its work. The ballpark will do .


Well they feel they have earned their due . For them if you can't do your pointer arithmetic right your a nobody...which I guess based on what they do everyday is a valid point.

I was young enough to come along by the time C++ had already started its rise and I prefer it over flat C any day .

C/C++ programming skills now in some cases are becoming very scarce. The big complaint in the field from many hiring managers now is that when they go out to talk to the college kids, most of them know C#, Java, VB etc. but not C/C++. They are still some jobs out there that need those skills but as the line from Harry Potter goes "there is a difference between doing what is easy and what is right".

jfitzpat

I think my points slipped by.

1. He isn't actually just accessing a serial port, he is accessing a USB peripheral, and has the 'managed' code doing additional work.

2. His current usage is basically your scheme. I wrote the relevant pieces in C++ and put it in an ActiveX control. I did that because it offers maximum tool coverage (VB, VB.net, C#...) It is slightly less convenient than true .net components, but all the hype about reliability and efficiency is just that, hype (don't believe me, do a little stepping in SoftIce).

So, from my point of view you are arguing solely that VB should be replaced by C#. The way I see it, it is a miracle that projects of any scope get written in either. Seriously, I have tremendous respect for folks who can develop an app of any size in either language. VB is, like a typical scripting language, extremely free form and lends itself well to chaos.

C#'s existance is something of a mystery to me at all. C++, like C, is inherently a system level language. C++ was not a radical departure from C. And despite the grossly overused inheritance mechanism, is primarily a C with better encapsuation. Both languages are still quite close to the machine. C# seems to be based on the idea that a simulation of a system level language, without system level power, is a good RAD environment. To me, it seems the worst of both worlds, a non intuitive, relatively low level syntax, but a lack of system level power. Place it on top of a truly ill conceived framework, and, again, it is suprising to me that folks get big things done at all.

What doesn't surprise me is the number of folks staying with VB. RAD environment users are generally just trying to get something done. From their point of view, there is little benefit to learning what is fundementally a system level language, just to access the same crappy framework and components.

Actually, I think I would detest the .net framework less if there was such an effort to present it as object oriented. When your string object inherits the ability to produce debug strings from your fundemental object, and knows less about the internal structure of strings than still another object, it is no longer surprising that Washington State has more varieties of hallucinagenic mushrooms growing natively than any other state in the union... Think about it, how else could 'Hungarian Notation' have come to exist? I know, let's de-encapsulate something as fundemental as a variable name...

Seriously, I agree with MJ. Delphi was probably closest to what a RAD environment should be. Pascal was developed as a computer science learning language and the Pascal with objects was quite well done.

It had a following, but once Microsoft bought VB the writing was, as you say, on the wall.

-jjf

Edit: If hiring managers are complaining about C++ skills, then they are stupid. The problem isn't language skills - languages come and go, just like OS's. The problem is fundemental programming skills, which have never been exactly plentiful. For example, we ask folks to write a simple program in 'psuedo code', or any language they like, to perform a simple task. Applicants always fall into one of three catagories:

An alarming number can't formulate a working algorythm at all, regardless of degrees or listed experience. Don't hire them.

Some can formulate a working scheme, these folks have promise, but will require investment.

A tiny number of folks formulate a working scheme and, automatically, put in handling for error cases. These folks can actually come in and produce in short order, rather they need to learn a new langauge and OS or not.

codgi

iTrader: (22)

Fair enough I read your post wrong then I guess....

Expand please .

Hungarian needed to die for a while and lo and behold it did when the chief proponent of it left the company. This unfortunately is the big problem of being dominant to the point of monopoly....one very very tiny person makes decisions that effects every one else...whether they are right or wrong.

Yes, I agree with you and my company is like yours. Also when the new people come in they get a chance to learn whatever they need to learn and are given smaller coding tasks to get up to speed (i.e don't let them go and change some core part of Office the first day at work).

However some people in the field don't have that luxury. They need someone to come in and write that C/C++ code (because for whatever reason no other langauge can do what they need done) and it needs to be written yesterday. So they don't have the "warm up" time to allow someone to learn the language. They need to be ready to go from day 1 and if thats what they need then they are going to go out there and hire that way.

Its a very "short termed" type of vision but it does happen out there.

galvitron

iTrader: (2)

This has mostly been covered, but I wanted to chime in...

As someone who develops in .NET languages (VB and C#) and C/C++ for a living, I see each with its own strengths and weaknesses.

.NET - good for rapid development, bad for optimal speed, need to install the framework

C/C++ - fast execution, takes longer to write, error prone, recompile to support other platforms.

One thing I commonly do is to write a .NET app with a modular structure and then go back later and convert single pieces to c++ as time and necessity dictate.

donour

iTrader: (6)

How did we get so off topic? I didn't expect to see such PL waxing on evom. Maybe this is the time for me to bring up ML, or haskell.

Oh. I have a better idea. I should go write a MUT library in Prolog. Can you imagine.

Seriously though, what's the point? This could go on forever and ever (and probably will). C and C++ are not the same. C++ is not a superset of C. It's a completely different language that shared a bunch of syntax (but not all). I certainly don't think here is anything wrong with high level/scripting/meta/whatever languages. I actually think it it important to program in as MANY languages as possible. Believe it or not, there are several dozen that I use on a regular basis.

Why did I write libmut in C? Why do I think that the mut code _needs_ to be written in C. Well, the OS interface is in C and libmut is supposed to be a system library. What else would be reasonable. If you want to use something else wrap it. I provide wrappers for 12 (yes twelve) languages. Nobody seems to notice that fact though.

MJ: I'm sorry if my pointers comment came across as arrogant. I don't really think that it was. It was just playful teasing. However what is arrogant (not directed at you) is to believe that someone else's skills aren't worth learning.

My problem with VB is not primarily the language specification. It is the fact that the only good implementation is closed source and available at a SIGNIFICANT cost. That limits the long term viability of the project. On this one I am very stubborn. Two pieces of software you need the source to.

1) your OS kernel
2) your development system.

d

MalibuJack

iTrader: (5)

I was actually busting your chops because we talk about this all the time. I happen to agree with most of the points here, only that working in the environments that I have to deal with, you dont have many options, so you need to be as proficient as possible in as many languages as possible. Unfortunately my life revolves around VB and VB.NET at my current job (UGH!)

Anyone who knows me knows I'm fairly proficient in many different things, but I choose my platforms carefully and with reason. I say Libmut needs to be written in LOGO, Cobol, or Fortran, preferrably on a TRS-80 or PDP-11 if you need higher horsepower and can tow a trailer.

jfitzpat

It might be argued that C++ is no longer a C superset, since the full ANSI feature set can no longer be implemented with a pre-compiler alone, but for the first decade or so, I can assure you - it was. Remember, it was called "C with classes" for years.

There were some more radical departures, like Objective C, but they died out.

Codgi: As far as elaborating, look back to a litmus test I proposed in the 70's - can a language be used to implement it's own compiler. Or, closer to the source, look to Dr. T. It was he, not I, that first pondered with 3.0 if C# had yet reached legitimate language status.

I don't know that I really disagree with anything Donour has said. To me, languages are just tools, some are built with different purposes in mind. I've literally lost count of the assembly mnuemonics I've learned. I *am* underwhelmed with Java and C# because I do not understand the reasoning behind adopting C like syntax and precedence headaches for high level, portable scripting languages. Both always seemed more like marketing than computer science, but that is just my opinion.

I also think that .NET was poorly designed at it's inception. Given the overhauls to date, I'm not alone.

I guess my fundemental point is that I see nothing wrong with using tools at hand and accomplishing something. It is like the huge arguments we used to have over vi and brief, totally missing the more important factors by focusing on relatively insignificant factors. People may think language is huge, but having written several applications wholly in 68K assembly language in the early days of MIDI, I tend to think that even languages, like editors, are less of a factor on productivity than you might think.

-jjf

donour

iTrader: (6)

Incorrectly of course. There is legal C code which is not legal c++ and some features work in completely different ways. Consider 'static' keyword. The C use of this has been completely absorbed by namespaces in c++ and 'static' is used for something else.

Go ahead, ask me about my porting pain. :-p

Don't tell apple that.

I actually think they are a _bigger_ factor than people realize, but not for the one people claim. I assert you need to the right tool for the job, and it never happens that something is the right tool for EVERY job. I'm afraid I started this EDIT:mud fight with the assertion that VB isn't the right tool for ANY job.

emacs forever!

.
.
.




d

donour

iTrader: (6)

I'll give you one better.

I N T E R C A L

Branching is only done with jumps -- but there's no GOTO. There's a COMEFROM.

oh. and before every assignment, you must ask please.

d

evo4mad

iTrader: (4)

jcs, next time you see me on MSN Messenger send me a message and I'll send you the SourceCode to EvoScan.

codgi

iTrader: (22)

Fair enough. Even though I would argue that since all the C# compiler does is spit out documented IL code you probably could have done this from C# 1.0.

"Scripting" languages now are supporting a whole lot more of the core software infrastructure today than they did even say 5 years ago. Having them use that syntax makes it easier for some of the "old hands" to port thier code and settle in.

On this same point, I meant to take a shot at your earlier comment on Pascal and its being developed as a computer science learning language. While I do like Pascal, I also don't know if I necessarily believe that just because a language was specifically developed according to some arbitrary CS guidelines that I can believe in it as being good for both developers and the final code produced. But thats a topic for another story .


Sun's JVM (easiest comparison) has gone through similiar overhauls in its recent past...go and compile old Java code with "-deprecate" on and see what I mean. The platform independent VM type concept went mainstream in the mid 90s and it will take some time to mature. But rest assured like it or not VMs and virtualization in general seem to be the way forward for the field (note more and more virtualization stuff is being built into the next gen OSes...and also note the increased number of companies who actually run their servers in VMs instead of on pure physical hardware).


Anyway this is now getting way off topic. It was fun though...we'll have a go another time I suppose .

jcsbanks

Thanks all. Hamish, I already have the Evoscan source you sent me in September, but never opened it until now when I realised it will also open in VB 2005 Express. There is a multi custom request ID utility that has been written for Evoscan that I posted on aktivematrix on my read/write address thread that works for now.

With so many clever people we should have more writing assembly code for the ECU It is a pointer festival! I have just booked my first ever two week holiday since I started working as a doctor nine years ago (only ever had a week before because of rotas!), half of it on a beach in Sri Lanka, and I can't just veg out in the sun and turn my brain off, so I'll have to learn something then - probably C or the preferred variant. It would mainly be an object orientated stuff to do PC stuff, and presumably just a very basic C to do microcontroller/ECU stuff. Suggestions on books/websites to learn anyone?

galvitron

iTrader: (2)

Back on topic: I also took a look at libmut and the LogWorks module source. Good stuff guys!

Back off topic: John, if you are going to learn a language right now I would suggest C++. The OOP foundation of it translate well into C#, VB, Java, etc.

Codgi mentioned above that VMs are the wave of the future. I agree. Platform portability is becoming more important than ever. Just think of how powerful cell phones will be in 10 years and keep in mind that the variety of manufacturers and platforms will still be there...they should all be targeted by the same source (in theory)

jfitzpat

By the creator? I'd think he would know what he was trying to do originally...

Serioulsy, If you haven't done so, it is well worth reading THE DESIGN AND EVOLUTION OF C++. Quite literally, the objective was to add classes to C. I had the benefit of seeing this fairly close up.

The language has evolved considerably, as has C. The K&R samples I first read would not compile with default settings on a modern C compiler. But the reason that the syntax is the same was because, quite literally, the original objective was to make an incremental improvement.

Of course, tools always get used in different ways than you would expect. When MIDI was new, we briefly discussed how simple and lame it was. But Chris at Sequential said that we were overthinking, it would only be used to connect two keyboards together. Simililarly, no one figured that major GUI applications would be written in C++. The thinking was that RAD tools would continue to involve. C++ was intended to be a better system level language. That is why features like inline, const, and so on, things that bite the performance minded, appeared right away.

Static had to evolve because there is 1 and a half extra levels of scope. However, firm C roots are clear, when you define a variable at the top of the file, it is inherently global, not file scope, by default, just like C.

Templates were inevitable, C's concept of casting was inherently non type safe. Although we pictured it a little differently, everyone knew early on that something like the standard template library was an obvious use of class inheritance. Namespaces came later, once the language was being designed by committee. Multiple inherentance is there to prove it can be done (though using it is generally a bad idea) and I've long thought that friend exists because I hated the very idea, but it is a lot more likely that they are there because Grady thought it was legit and useful.

As far as Objective C, don't be confused by the namesake. I'm referring to Coad's pioneer work on inheritance and scope. In very early post production Digital Audio circles, Paul Hershenson convinced me that it was a workable modal and the first edit based digital audio filesystem was based on a naming convention and simple pre-processor tool we rolled internally (Edit based means that files only duplicate large, raw sound data, when required and raw blocks are protected by reference counts).

We kept strict rules on the use of inheritance, which is something many projects might benefit from today. The C++ 'style' that so many people seem to feel they need to adopt actually leads to a lot of extra lines and hidden code dependancies.

This sort of pointless use-it-just-because-everyone-does, like hungarian notation, can make porting a real chore. But, again, the langauges share syntax because the original name and the final name reflect the goal, an incremental improvement on a successful langauge.

C#, on the other hand, was a new scripting language, so the choice of C/C++ syntax was somewhat arbitrary and, I think, probably a big part of VB's continued popularity.

As far as the tools, lots of folks think as you do. I'm in the minority. I'm used to it. I also think that winging it is generally bad (I write experimental test code as well, but I discard it once I've learned what I need to know). I'm also a big fan of designing for testability, a concept that has never really caught on in the main stream.

Sorry we are off topic, it is actually an area of interest to me, particularly since I don't have a programming 'faith'. Again, things come and go, I think it is the ability to break problems done into solvable chunks, build those chunks, etc., that holds value over time.

-jjf