Re: newbie question

Hi Lisa,

Your persepective is skewed by your experience. The programming stack has
grown since nearly day 1, with the invention of Assembler. Every time the
programming stack grows, somebody has something bad to say about it. But
there is a good reason why this is so. Productivity.

As programming evolves (and it certainly DOES evolve), it becomes more and
more complex to do things which people ordinarily take for granted, such as
simply running more than one program at a time (which, as you and I both
know, is impossible). As no more than one program can run at a time, the one
program that runs all the time is the OS. It spawns threads in its execution
loop that make it look as if the OS is running many programs all at one
time. The complexity of this alone demands a programming stack, an OS API,
which Microsoft refers to as a "platform." But of course, this is at the OS
level. On top of this platform are running all kinds of applications.

The sheer size and complexity of this situation demands OOP. I once read a
book on Windows programming in C (not C++). Windows was originally written
in C, not C++, and was one big procedural app. Do you know how many lines of
C code it took to create a simple window? Hundreds. There are all kinds of
structures in there, and pointers, and messaging, etc., all of which had to
be programmed into a gigantic loop. Obviously, things were getting out of
hand with procedural programming. Hence, OOP was born.

Now we are living in the next generation of programming. Again, complexity
dictates that we build another layer on the programming stack. The .Net
platform is an attempt to sove these inherent problems, such as DLL Hell,
Memory Leaks overlooked by programmers, etc. it works much like Java, in
that it is patform-independent, compiles to byte code, and requires a JIT
compiler to run, and for the same reasons. But it has a significant
advantage over Java: you can go as low-level as you need to, when you need
to. IOW, it's the best of both worlds, just as C++ didn't REPLACE C; it
extended it. C# doesn't REPLACE C++; it extends it.

Now, all this talk about Microsoft bloatware is just old. Microsoft USED to
put out bloatware, and for reasons that I won't go ito here, but they were
temporary and legitimate. But Microsoft software hasn't been bloated for
years now; people in the Unix crowd are just not current regarding
Microsoft.

In fact, the .Net platform provides one other thing that I didn't mention:
code consistency. When you use the Microsoft .Net stack, you are using a
standard set of classes, which most .Net programmers are familiar with. This
means less time ramping up to modify or extend an application. And, as
programmer time is the single most expensive cost of software development,
that's a GOOD thing!

Microsoft has been underestimated since its inception. Come on in, the
water's fine!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.




"Lisa Pearlson" <no@xxxxxxxx> wrote in message
news:upoKAssOFHA.4028@xxxxxxxxxxxxxxxxxxxxxxx
> Exactely.. it doesn't matter if it's C/C++/Java/PHP/ASP.. code is code..
> no matter how you write your for/next loops.. the logic is the same, the
> syntax is different.
>
> But like in my post I write just before I read yours, learning CLR is
> indeed a very steep learning curve..
> I don't want to have to know, but have to understand, and be able to
> figure everything else out myself.
>
> I compared .NET to chinese and C/C++ to the latin alphabet.. with only 26
> characters to learn, we can write everything we want.. chinese have one or
> more characters for whole words or sentences... which makes writing more
> efficient.. but only after you've become familiar with at least 3,000
> characters, up to 50,000 or more.. and that's just not the way to go in my
> opinion.
>
> I want reusable words, not new characters.
>
>
> "Kevin Spencer" <kevin@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:eUKFXbsOFHA.3668@xxxxxxxxxxxxxxxxxxxxxxx
>> Hi Lisa,
>>
>> I think you would benefit from the freely downloadable .Net SDK:
>>
>> http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=en
>>
>> No, you won't have any trouble at all learning C#. With a few exceptions,
>> it's just like C++.
>>
>> What you WILL take some time to do is to learn the CLR (Common Language
>> Runtime Library). This is arguably the hardest thing to get familiar with
>> regarding .Net. There are just so many classes in there. Of course,
>> that's actually a GOOD thing; as the classes already exist, you don't
>> have to write as much custom code. Fortunately, the namespaces and
>> classes are organized extremely well.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> .Net Developer
>> What You Seek Is What You Get.
>>
>> "Lisa Pearlson" <no@xxxxxxxx> wrote in message
>> news:uEeHhMsOFHA.2748@xxxxxxxxxxxxxxxxxxxxxxx
>>> Thank you for your feedback. I really appreciate it, and I did not
>>> dismiss anything.
>>> I'm an experienced C++ programmer. I'm not worried about learning C#.
>>>
>>> I do not expect people to support me in my .NET dislike or all other
>>> layers of abstraction, starting with COM. I understand the advantages,
>>> but not sure it needs to be that complex. If I wanted to to be affirmed
>>> in my dislike, I wouldn't be posting on a microsoft news server, but on
>>> a linux website.
>>>
>>> My sole purpose was to learn enough about .NET to know if it can be a
>>> better tool for the job.. (not only technically, but also market
>>> acceptance.. if customers want it, and maybe later want connectivity
>>> with other microsoft products, then using microsoft products is a better
>>> choice, even if I hate it.. I have to give what the customer wants. I'm
>>> accepting my miserable fate).
>>>
>>> At least I'm not dimissing .NET indefinitely.. For me to judge if it is
>>> the right tool for the job or not, I need to know enough about it to be
>>> able to make that judgement, and I don't know enough yet.
>>>
>>> Your response has helped me quite a bit.. and I am leaning towards using
>>> PHP has a draft, and then program a windows C++ application with ODBC.
>>> Perhaps even embed HTMLView so I can use the ease of web as well as
>>> power, flexibility and speed of C++.
>>>
>>> I'm not done learning about .NET yet though.. If you can't beat them,
>>> join them.. resistence is futile, we'll all be victimize by this
>>> monopoly. :-) owwwww
>>>
>>> "Dave Fancher" <eijitek@xxxxxxxxxxx> wrote in message
>>> news:0_ednchVhaEe4M7fRVn-rg@xxxxxxxxxxxxxx
>>>> For what you have described, ASP.NET doesn't sound like the tool for
>>>> you. You want a client side technology (ActiveX or Java?) that is able
>>>> to create and maintain a connection to a database. You don't need
>>>> ASP.NET for what you have described. I think a desktop application is
>>>> better suited for this application.
>>>>
>>>> To fill you in, the way the event model works in ASP.NET is that each
>>>> control that triggers a server side event calls a client side
>>>> JavaScript function that sets the value of a couple of hidden fields
>>>> then submits the form (a standard HTML form with a runat="server"
>>>> attribute). There is another hidden field called ViewState that allows
>>>> for persisting values between server trips. Additionally, each page
>>>> follows a specific life cycle of events that handle code specific to
>>>> intialization, loading, event handling, rendering, and unloading.
>>>>
>>>> For instance, if you have a Button WebControl (rendered as <input
>>>> type="button" ...>) that has a server side handler for onClick, the
>>>> button is also rendered with onclick="__doPostBack(...);" which sets
>>>> the hidden fields and submits the form. The .NET runtime (on the
>>>> server) checks the value of the hidden fields (including viewstate) to
>>>> determine the status of the page and executes the method that is
>>>> specified to handle the event.
>>>>
>>>> The model used by ASP.NET allows for much more managable code not to
>>>> mention that is succeeds in isolating the logic from the UI code (HTML)
>>>> since, when done properly with code behinds (VS.NET default), the HTML
>>>> document (your aspx file) forms the layout for a class ultimately
>>>> derived from System.Web.UI.Page. With a code behind, you define a
>>>> class derived from System.Web.UI.Page. When an ASPX is requested, the
>>>> runtime instantiates a class derived from the class defined in the code
>>>> behind file.
>>>>
>>>> If all your application needs to do is retrieve and edit database
>>>> records, you may be able to pull this off in a month but that entirely
>>>> depends on the actual complexity of the app. Overall, the WebControls
>>>> and HtmlControls are pretty straight forward. ADO.NET is also pretty
>>>> straight forward. Depending on your environment and application needs
>>>> though, security considerations (which it sounds like you'll have from
>>>> your issues over control) offer their own set of complications. Of
>>>> course, there are nuances to all of these topics about which you should
>>>> educate yourself.
>>>>
>>>> Agreeing with Scott M., IIS is easy to configure. I'm running six
>>>> ASP.NET apps and have development, testing, and production environments
>>>> set up for each of them. Very little configuration is needed to
>>>> properly configure IIS for an ASP.NET application. Granted, IIS
>>>> configuration is not done through config files but to argue your point
>>>> about Apache working "out of the box", you said it yourself, "configure
>>>> some options in a config file, ..., install PHP, ... and off you go."
>>>> How much does that really differ from "install the .NET Framework,
>>>> click a button or two to configure some options, and off you go." In
>>>> either case, you must still create the application folder and tell the
>>>> HTTP server where the application is loaded.
>>>>
>>>> As for learning the .NET technolgies, learning a .NET language
>>>> shouldn't be a big deal. If all else fails you could even use PerlASPX
>>>> from ActiveState to allow you to use Perl instead of C#. Sure, there
>>>> are differences between languages in that some languages offer features
>>>> that other languages don't but the overall concepts are the same and
>>>> common constructs are only syntactically different. No matter how it
>>>> is written, a for loop is still a for loop.
>>>>
>>>> When push comes to shove and you're up against a wall, you need to
>>>> choose the best tool for the job. For your situation, it sounds like
>>>> you should stick with a tool with which you are already familiar. In
>>>> fact, your posts read as though you have already convinced yourself not
>>>> to use the .NET technologies for a variety of reasons that are
>>>> applicable in some cases and not in others. You seem to be dead-set
>>>> against using the .NET technologies and are looking for people working
>>>> in completely different environments with different needs to either
>>>> validate your concerns (further proving that .NET is not worth your
>>>> time) or to give you some irrefutable argument as to why you absolutely
>>>> must use .NET as opposed to the other tools at your disposal. To
>>>> reiterate, you must evaluate the needs of the project and choose the
>>>> tool that you believe will best meet those needs. If you believe
>>>> ASP.NET is the best tool, great, use it, otherwise use something else.
>>>>
>>>> On a side note, if you're dismissing at least 80% of what you read, it
>>>> sounds like you may want to refine your search techniques or perhaps
>>>> you're simply disregarding too much...
>>>>
>>>> Good luck with your project.
>>>> ----------------
>>>> Dave Fancher
>>>> http://davefancher.blogspot.com
>>>>
>>>> "Lisa Pearlson" <no@xxxxxxxx> wrote in message
>>>> news:%23B8LrZlOFHA.1396@xxxxxxxxxxxxxxxxxxxxxxx
>>>>> Thank you for your response.
>>>>>
>>>>> I find that most of my time learning new stuff is wasted on searching
>>>>> for the right info.. and digging through 80% or more of useless
>>>>> chatter around it, yet having to read it all to know what is chatter
>>>>> and what is not.
>>>>>
>>>>> If you're a good programmer, you can make applications robust and
>>>>> scalable without the .NET framework. But since .NET is advertised well
>>>>> and clueless customers want it, I'm pretty much forced to swallow this
>>>>> new technology which is yet again another wrapper around all these
>>>>> microsoft technologies, that I frankly dislike. One reason why I never
>>>>> liked VB. To much behind the screen wiring.
>>>>>
>>>>> Anyway, I should be able to develop something within 1 month, and
>>>>> maybe fine tune things later.. doing the project will be like
>>>>> following a tutorial, where I have to search the net for clues as to
>>>>> how to take the next step. Best way to learn.. But pretty stressful
>>>>> when you have a deadline too.
>>>>>
>>>>> Away from my petty life, back to ASP.NET, you mention "event driven
>>>>> model".. I'm sure all this info is available on the net, but like I
>>>>> said, 80% of my time is wasted on searching for it, so this helps me
>>>>> alot..
>>>>>
>>>>>
>>>>> Question:
>>>>> How should I understand event driven model in web applications? on
>>>>> client side, javascript can handle some events, everything else is
>>>>> usually done via form POST and parsing on the server side, using ASP,
>>>>> PHP or whatever.
>>>>> Do events on the client side get sent to the server? Via HTTP
>>>>> messages, or via DCOM bloat?
>>>>>
>>>>>
>>>>>
>>>>> I've found so many sources dealing with ASP.NET but none that just
>>>>> explain some of the basics of what ASP.NET is really all about. I've
>>>>> read upon some .NET stuff, and it seems little more than a thin
>>>>> wrapper around windows APIs to handle some garbage collection and
>>>>> such.. (to use api's you have to write your own wrappers sometimes..
>>>>> reminds me of VB, where to do anything useful, required you to import
>>>>> half the windows api's.. so then why not use VC++ instead, I always
>>>>> wondered).
>>>>>
>>>>> Lisa
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


.

Loading