Easiest programming langauage you've ever learned?

[eklass]

learn C/c++. it'll never do you wrong and the techniques will be infinitely useful. not to mention you will understand how other languages compares to the "big brother"

althought knowing PHP (very close to C) made c very easy, the concepts i learned in my c++ were indispensible

if only someone would come up with a compiler for php + gtk(do i hear an x86 asm volunteer?), i would never need any other language

 

[Barnaby W. Füi]

Originally posted by: eklass
learn C/c++. it'll never do you wrong and the techniques will be infinitely useful. not to mention you will understand how other languages compares to the "big brother"

althought knowing PHP (very close to C) made c very easy, the concepts i learned in my c++ were indispensible

if only someone would come up with a compiler for php + gtk(do i hear an x86 asm volunteer?), i would never need any other language

EEEEWWWW!!!

1. Just MO of course, but all gui toolkits (that I've looked at) SUCK to code. The exact opposite of "nice and tidy" code.
2. PHP - ick! It's nice for the web because it has lots of web functionality built in, but strictly as a language, it pretty much stinks.

 

[calpha]

Originally posted by: BingBongWongFooey
Interesting, I always figured vb was fairly fast, considering you "compile" it in the IDE, and it just links to dll's and stuff, I figured most of the final code running was essentially just c++.

Actually, vb is compiled to C code, not C++....I really wasn't after a language rip thread....just interesting to see what the easiest someone ever learned was.

PHP doesn't count BTW. NOT A LANGAUGE.
Loosely Typed Scripting Language----there is a difference.

 

[Barnaby W. Füi]

PHP doesn't count BTW. NOT A LANGAUGE.
Loosely Typed Scripting Language----there is a difference.

That's such BS. You even just called it a language yourself. Is it a *great* language? NO! Is it a language? Duh!!!

But knowing php alone definitely doesn't make you much of a programmer

 

[Descartes]

Originally posted by: glugglug

Originally posted by: Descartes
For the record, making claims on performance (or lack thereof) are unfounded unless proper documentation can back it up. "sick joke" doesn't exactly quantify anything.

I'll venture that 90% of VB applications employ COM components written in C++, so the overhead is in COM, not the language itself.

OK, I'll back it up.....

Calling a C++ COM function that does nothing but return the system uptime in seconds as a double from a separate C++ application takes 1.99 microseconds per call on a 2GHz Pentium 4.

From "native" compiled VB this same COM method call takes 60 microseconds. The slowness isn't just COM overhead because C++ managed to deal with the extra overhead on the same COM function in just over 3% the amount of time.

Interestingly enough, VB is less efficient with COM than it is with normal method calls, but still nowhere near the speed it should be on those normal calls. Calling the function in the above example as a normal DLL method instead of through COM takes a little over 1 microsecond in C++, but 7 microseconds from VB, so the ratio of VB time to C time becomes 7 to 1 for normal Win32 DLLs vs. 30 to 1 for COM methods (assuming 0 time for the method call itself). I guess its possible (hell probably, I've got the overhead of a call to kernel32 within the COM method) that the ratio is worse than 7 to 1 for normal DLLs as well, just that the code WITHIN the call being executed is taking most of the 1 microsec from C++.

Sorry, not near enough information. I'd need to see both implementations in order to validate your statements. Note, I don't think anyone is arguing that C++ is a much better performer over VB, I'm just noting that the "sick joke" comment was absurd.

VB by default implements a dual-interface component, did you do the same in C++? Was the call to the method vtable/early/late bound? Were the calls made to an in-process COM server?

Seriously, comparing C++ to VB performance-wise is like comparing apples to oranges, but that doesn't mean the oranges are rotten.

 

[glugglug]

The COM component was the same C++ compiled DLL in both cases which did not have a dual interface.
In process call to an early-bound component in both cases -- even C++ takes most of a millisecond for out of process.

Also, in both the VB app and the C++ app I create the object then call the uptime method twice so that there is no object creation going on in-between the calls in order to figure out how long each call takes.

 

[calpha]

Originally posted by: BingBongWongFooey

PHP doesn't count BTW. NOT A LANGAUGE.
Loosely Typed Scripting Language----there is a difference.

That's such BS. You even just called it a language yourself. Is it a *great* language? NO! Is it a language? Duh!!!

But knowing php alone definitely doesn't make you much of a programmer

Man, I'm talking about programming languages that were easy to learn here....not semantics of what is and what isn't a langauge.
Are scripting langauges langauges? Sure. Are they included in my original question? NO. End of story.

IS VBScript a language? No. It's a subset of VB. Same with ASP. So, there we both win. [edit---deleted....broken train of thought Is php a language? ][/edit]

yes, there's a helluva lot you can do with Perl, PHP, ASP, vbscript---that's for sure. But pretty much, you most likely had to get started somewhere else to learn about typing, variables, and all of that (no, I'm not saying all do.....but I went to a school where a lot of mass comm people would TRY and take web classes to add some programming onto their resumes...and it was very fun to see them struggle through a hello world javascript function).

 

[Descartes]

Originally posted by: glugglug
The COM component was the same C++ compiled DLL in both cases which did not have a dual interface.
In process call to an early-bound component in both cases -- even C++ takes most of a millisecond for out of process.

Also, in both the VB app and the C++ app I create the object then call the uptime method twice so that there is no object creation going on in-between the calls in order to figure out how long each call takes.

Please post the respective VB code, including where you create the object. If one isn't familiar with how the underlying CoCreatInstance() calls are made with respect to VB object instantiation, they might not understand the performance degredation.

 

[calpha]

Sorry, not near enough information. I'd need to see both implementations in order to validate your statements. Note, I don't think anyone is arguing that C++ is a much better performer over VB, I'm just noting that the "sick joke" comment was absurd.

VB by default implements a dual-interface component, did you do the same in C++? Was the call to the method vtable/early/late bound? Were the calls made to an in-process COM server?

Seriously, comparing C++ to VB performance-wise is like comparing apples to oranges, but that doesn't mean the oranges are rotten.

Descartes.....you must have been programming since windows 3.1, or been a c / c++ programmer for a long time.

I agree with you---IMO, no point in comparing C++ efficiency to VB at all. In my thread you answered earlier last week---I was suprised by comparing .NEt to C++ how much slower it was in my 3 examples.....but as far as VB to C++, C++ will win hands down every time, except in one area. And that's speed and ease of use for me.

Besides....with 1.5 ghz being a fairly sustainable minimum in a client install base, the end user probably woulnt' notice any speed issues on a standard vb db application. I still don't think that VB is as slow as JAVA. But that's just my experience. God knows....I quit using morpheus a long time ago....but the gui itself would take a year to come up on my PC.

Incidentally---.net for me has been one of the hardest langaues for me to learn. Simply because I'm stubborn, and I hate having to basically throw everything I've learned in the past 6 years out of the door....but there's just a lot of changes going on.

 

[calpha]

Originally posted by: Descartes

Originally posted by: glugglug
The COM component was the same C++ compiled DLL in both cases which did not have a dual interface.
In process call to an early-bound component in both cases -- even C++ takes most of a millisecond for out of process.

Also, in both the VB app and the C++ app I create the object then call the uptime method twice so that there is no object creation going on in-between the calls in order to figure out how long each call takes.

Please post the respective VB code, including where you create the object. If one isn't familiar with how the underlying CoCreatInstance() calls are made with respect to VB object instantiation, they might not understand the performance degredation.

I'm no COM Expert at all....but Descartes are you referring to the innate diff't compiler and performance wise in VB between:
Dim x as ComObject
set x = CreateObject("qualifier.classname")

versus

Dim x as New ComObject?

 

[Descartes]

Originally posted by: calpha

Originally posted by: Descartes

Originally posted by: glugglug
The COM component was the same C++ compiled DLL in both cases which did not have a dual interface.
In process call to an early-bound component in both cases -- even C++ takes most of a millisecond for out of process.

Also, in both the VB app and the C++ app I create the object then call the uptime method twice so that there is no object creation going on in-between the calls in order to figure out how long each call takes.

Please post the respective VB code, including where you create the object. If one isn't familiar with how the underlying CoCreatInstance() calls are made with respect to VB object instantiation, they might not understand the performance degredation.

I'm no COM Expert at all....but Descartes are you referring to the innate diff't compiler and performance wise in VB between:
Dim x as ComObject
set x = CreateObject("qualifier.classname")

versus

Dim x as New ComObject?

That's the difference betwen late and early binding, and from what he said, he's early binding. One thing I was referring to was how VB will lazy-initialize the COM component instantiation. e.g.:

Dim foo As New SomeComponent
foo.Foo

Every method call in the above will be first checked to see whether the instance is null; thus the lazy-initalization. This is a bit of overhead that could account for a least a few microseconds

 

[calpha]

That's the difference betwen late and early binding, and from what he said, he's early binding. One thing I was referring to was how VB will lazy-initialize the COM component instantiation. e.g.:

Dim foo As New SomeComponent
foo.Foo

Every method call in the above will be first checked to see whether the instance is null; thus the lazy-initalization. This is a bit of overhead that could account for a least a few microseconds

[/quote]

Well, I knew that much But I've never heard it called "Lazy Initialization" but it's an apt term if I've ever heard of one. I figured that's what you were talking about though.

So...whendid you start programming for moneY? Pre winders 95 or longer then that?

 

[glugglug]

Originally posted by: Descartes
Please post the respective VB code, including where you create the object. If one isn't familiar with how the underlying CoCreatInstance() calls are made with respect to VB object instantiation, they might not understand the performance degredation.

Um...
I'm trying to reproduce the code since I don't have it with me and now its taking a MUCH more reasonable 2.7 microsec from VB. Don't know what I did wrong on that COM call the first time, or how a regular DLL call can possibly be slower than a COM method call.

I'll have to look at the original code tomorrow, my best guess right now is that maybe I did give it a dual interface so that I could try calling it from ASP.

 

[Descartes]

Originally posted by: calpha

That's the difference betwen late and early binding, and from what he said, he's early binding. One thing I was referring to was how VB will lazy-initialize the COM component instantiation. e.g.:

Dim foo As New SomeComponent
foo.Foo

Every method call in the above will be first checked to see whether the instance is null; thus the lazy-initalization. This is a bit of overhead that could account for a least a few microseconds

Well, I knew that much But I've never heard it called "Lazy Initialization" but it's an apt term if I've ever heard of one. I figured that's what you were talking about though.

So...whendid you start programming for moneY? Pre winders 95 or longer then that?[/quote]

It's usually called lazy loading, but in the context of COM lazy initialization makes more sense as the COM component is loaded in-process often before an instance of a given coclass is instantiated.

I started working professionally about 5-6 years ago, and at the time Windows 95 was happily commencing DLL hell. I started programming under DOS in Turbo Pascal 7 and C, but didn't do a lot of Windows apps in 3.x; however, I'm quite familiar with Windows architecture, and Win 3.x artifacts have always been present.

 

[glugglug]

Is there any way to make VB force you to do things the right way, i.e. forced TYPE for every variable, not just forced declaration?

 

[Descartes]

Originally posted by: glugglug

Originally posted by: Descartes
Please post the respective VB code, including where you create the object. If one isn't familiar with how the underlying CoCreatInstance() calls are made with respect to VB object instantiation, they might not understand the performance degredation.

Um...
I'm trying to reproduce the code since I don't have it with me and now its taking a MUCH more reasonable 2.7 microsec from VB. Don't know what I did wrong on that COM call the first time, or how a regular DLL call can possibly be slower than a COM method call.

I'll have to look at the original code tomorrow, my best guess right now is that maybe I did give it a dual interface so that I could try calling it from ASP.

If you implemented it in VB, you didn't have to give it a dual-interface; it's implemented for you (quite unfortunate in most cases). There's generally not a lot of overhead in dual-interfaces, but the cross-interface delegation often performed (else you'd have to have two almost identical implementations) results in enough overhead to make a few microseconds of difference. When VB developers went pseudo-OO crazy back in the Windows DNA days, they would create user-defined interfaces and implement them to allow polymorphic behavior. The problem was that the dual-interface was still implemented, but not for the user-defined interface, so late-binding clients (VBScript) couldn't use the user-defined interface. The typical solution was to delegate calls from the main class (i.e. not the interface implementation) to the user-defined interface, but that added even *more* overhead.

The point of the above is that the decision to use VB in these cases was never for performance reasons, but usually for architectural/financial reasons (i.e. if you have clients who have in-house VB developers, or if you need a quick time-to-market, etc.).

 

[Smilin]

Pascal.

It was designed as a learning language. It's very strict on syntax and forces you into at least halfway decent programming practices.

 

[BFG10K]

Applesoft BASIC. I also picked up HTML very quickly too.

The hardest language I've ever used was Haskell. I just couldn't get my head around how it worked.

 

[Barnaby W. Füi]

I wouldn't call html a programming language

 

[glugglug]

I found this page pretty interesting:
Computer Language Shootout

It has benchmarks of many textbook problems solved in tons of different languages/compilers, with source.
Looks like Delphi's optimizer is a lot better than I thought there.... actually I think its a side effect of their odd decision to do everything with default compiler settings. Debug info in delphi is compiled completely into a separate file, not your target .exe or .dll, so having it on doesn't slow down execution and I think that is the reason it scores faster than VC++ in most of the tests at that site. (Almost every compiler has debug info on by default).

 

[calpha]

Originally posted by: BingBongWongFooey
I wouldn't call html a programming language

Naw, then it'd be HTPL.

 

[Mallow]

Pascal, HTML and Basic are right up there ^_^