testimonials

[Tuxman]

Lisp... isn't that... the one... oh, god... there's a black worm in my brain... Parenthephobia!

Of course, "(" and ")" are very annoying for those who prefer languages with "(" and "[" and "{" and their closed counterparts.

Why would you want to have a clear syntax anyway?

[Kilmatead]

I have spent this year learning the basics of C++ which has lead me to understand certain things of .NET's most used languages.

Erm... here's a big latin word for you: "Non-sequitur": C++ has nothing whatsoever to do with .NET, and the longer it stays that way, the better off the world will be, safe from mental harm and disease.

Although I have a PHD, as you know, we are always newbies. The good thing is the fact of facing new learning challenges that improve your professional skills and, moreover, if you do it also for pleasure.

Where I come from, that's called admitting that "although you're unemployed, you're a highly educated unemployed person".

Why would you want to have a clear syntax anyway?

So I can laugh and point at the AutoHotKey people as they chase after the bus they mysteriously keep missing year after year.

[Tuxman]

C++ has nothing whatsoever to do with .NET

I'm sure there is .NET for C++. There is even .NET for Common Lisp.

[Kilmatead]

Yes, of course there is - that's CLR (Common Language Runtime) integration - did you not ever wonder why Windows Update insists upon downloading so much .NET nonsense every month even if you' go out of your way to avoid .NET dependency-programmes? It's a Windows component like any other, essentially just a very very very bloated runtime library (well, "environment", really), like Java and its virtual-environment, except you don't have a choice about installing it (practically speaking). The CLR treats everything as managed-code, regardless of the code's true provenance.

The 4.0 version of .NET for standard 32-bit Windows systems requires 850 MB of free space on your primary Windows drive; a 64-bit Windows system needs 2 GB free

So sure, in much the same way as Windows loads the (relatively tiny) API DLL's it requires (such as shell32, etc) whenever you run a stock executable, the .NET framework is always lurking in the background, just waiting to spool up and kick puppies and spit on old people waiting at bus-stops (you can always tell a .NET application by the delay in its startup no matter how fast your computer).

This is largely what "Visual" means, and if you give people a large library of blind spaghetti-code to use, they won't turn it down, they'll say, "Yeah, no problem, my customers will just have to adapt to my lazy attitude". Especially popular as an entry-point for kids learning Visual Basic: infect them while they're young.

My point was that while C# as a language was created from the ground-up to be 100% .NET dependant, the C++ language (or any other non-"Visual"-moniker) does not actually have anything to do natively with the framework, and so they should never be connected. Much the same way as the people on Stack Overflow will bend over backwards to (rightly!) point out that C and C++ are two completely different languages that just happen to share a compiler-methodology (contrary to the impression that Wikipedia would give you), anything that is connected to the .NET knowledge-death-cult exists in name-only once it's infected (due to the way the JIT runtimes work).

So, even though I am loath to admit it, C++ programmes may be considered "pure" in their compilation-state; but C++ that uses .NET is no longer really C++... it's just a scripting language co-opted into the service of corporate consumers and given a name that "sounds like" the real thing to catch out the unwary questing hero.

Did you ever wonder why very few professional 3rd-party programmes are written in .NET? Most utilities are based in C or Delphi or C++, or other such traditional foundations - no one writes .NET applications for the independent-developer eco-system, they write them as a queer mix of (in-house) business-support, and the kids who don't know any better but hear so much about it that they assume it's actually used by real people. No one would ever proudly display on their website that "This product is 100% pure .NET!" - instead, they write at the bottom in a creepy and apologetic tone, that "it requires .NET". Did that not ever strike you as a bit odd and furtive?

So (previously in this thread) when sanferno asked Nikos if "you develop x2 and DR using Visual C++, don't you?", Nikos mistakenly answered "yes", when what he really meant was just "in the IDE", not ever even thinking that someone would or could mis-associate that with the .NET corporate-umbrella of "Visual".

That was the distinction I was trying to make, in my usual long-winded way.

But what do I know? I'm just a gardener after all.

[sanferno]

So (previously in this thread) when sanferno asked Nikos if "you develop x2 and DR using Visual C++, don't you?", Nikos mistakenly answered "yes", when what he really meant was just "in the IDE", not ever even thinking that someone would or could mis-associate that with the .NET corporate-umbrella of "Visual".

By "Visual C++" I was referring to the so called "Managed C++". What you call "Visual" as an IDE, that is for me "Visual Studio" in its many versions.

Being now an intuitive person (hope I'm not misplaced), Nikos develops using Managed C++, doesn't him?

[Kilmatead]

Nope, no "managed" code. He's responsible for every pimple, fart, and smelly toe, as it should be. Besides, since he maintains backward compatibility for OS's even earlier than XP, managed code could never work. He does, however, use some awful WTL stuff for GUI aspects, but that's still fairly low-level.

See this blog.

[Tuxman]

It could be worse. He could use GTK+ instead.

[Kilmatead]

Or wxWidgets, or Qt, or a hundred other so-called cross-platform bits... (except WTL is not CP, it's Win-only). No matter how much development goes into these wrapper-sets, they still can never get it quite right, especially if you take DPI into account. Even the latest release (just last week) of the Embarcadero toolchain (for you Delphi lovers out there), is horribly bugged with DPI scaling on Windows. You'd think it couldn't be that difficult, since it really is WinAPI underneath anyway.

[Tuxman]

Not that Microsoft's own frameworks would be better in this. I've seen quite a lot of WPF applications which look horrible on any other than one certain, rather exotic resolution.

[Kilmatead]

Well sure, just because .NET (WPF) gives people all sorts of silly ready-made GUI toolkit-bits to mess around with, it's not 100% idiot-proof. You have to allow a little bit of room for the human-element to screw things up, or .NET would just write itself - but maybe that's MS's goal anyway?

[Tuxman]

Self-writing code? By Microsoft? Now that would be scary...

[sanferno]

Nope, no "managed" code. He's responsible for every pimple, fart, and smelly toe, as it should be. Besides, since he maintains backward compatibility for OS's even earlier than XP, managed code could never work. He does, however, use some awful WTL stuff for GUI aspects, but that's still fairly low-level.

See this blog.

Well, that is really being a badass, how I'm not going to admire those abilities in some kind of way? Though I learned the basic stuff with C in 2009, I have been doing my little things in .NET (VB most of the time, and some C#) during the past five years, but I have never had the feeling of being a pro. Then by this time of last year I started to learn C++ (most for the pleasure, but also for being unemployed as you stated correctly yesterday), and I quite enjoyed the process. Now, WinAPI seems to be real hard, but why I shouldn't be able make it?

PD: most of my interest in programming it's for managing data, tabulate, etc. Most of the times raw data does not allow you to perform analysis.

[pj]

...
PD: most of my interest in programming it's for managing data, tabulate, etc. Most of the times raw data does not allow you to perform analysis.

As I'm also a big (and small) data person, my programming language/platform of choice is VBA within Excel. I've even written some simple tools using Excel automation where the only GUI that shows is the Userform. It's like back in APL days with all the data present and accessable in the workspace and the programs interact with the data at will. Only then the workspace was all of 64K bytes and the programs were unreadable

So now with Excel I have a fully integrated IDE, a comprehensive object model to work with, access to the full WinAPI-verse and other 'verses by reference (like SAP), and the workspace is now on the order of up to about 2GB on my machine before things get really bogged down.
---------------------------
PJ in (yeah, I really DO feel like hijacking this topic today) FL

[sanferno]

As I'm also a big (and small) data person...

Work is usually better with some with some good music, this gets even better if we fit the topic...

https://www.youtube.com/watch?v=hsvK8WCPj1Y