My view of the world


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 4 123 ... LastLast
Results 1 to 15 of 56

Thread: My view of the world

Hybrid View

  1. #1
    Kevin Moore Guest

    My view of the world


    Hi,

    I just wanted to get up on my soap box and offer some insight into my world
    and hopefully get some feedback from y'all. I have been developing app for
    the last 12 years, the last 6 of which has been predominantly with MS technologies
    focusing on VB and SQL. I split my time between consulting to clients and
    developing commercial apps. For my commercial app I use VB (6) and SQL 7/2000
    and have been doing so for several years. For my consulting I use C++, COM+,
    ASP or whatever the client chooses.

    Now onto the rant. Within the scope of my commercial app, I chose VB because
    it was simply one of the best RAD tools on the market, I could accomplish
    all of my goals, quickly and easily and I was able to migrate through the
    various release moving from VB3 -> VB4 -> VB5 to finally VB6. Along the way
    I enjoyed taking advantage of newer technologies that MS has implemented
    with the language, eg VB5 native compiler and VB6 COM+ integration, VB4 classes
    (ok not really due to the problems, but close). Now I come to .Net and I
    must say from my commercial app point of view I am quite disappointed. Just
    to clarify I have been working with .Net Beta 2 since last Sept. When I first
    heard about .Net I was hoping that MS would go the way of Delphi in offering
    Static linking and remove us from the dependecy on MSVBVMx.DLL, when I heard
    about the CLR I was initially pessimistic. Over the time my pessimism has
    turned to downright frustration.

    I have serious doubts of MS's claim that the CLR (20 Mb at least) in size
    will be easily updated and will remain backward compatible. They haven't
    really done the backward comptability in the past so why should they start
    now.

    For the sake of my commercial apps I am left with some choices and I would
    hope that y'all might offer some other insight.

    1. Move to .Net, continue the learning cycle of VB.Net and hope that MS deals
    with the CLR correctly.
    2. Move to Delphi and learn another language
    3. Stay with Classic VB and become antiquated (not really an option)
    4. Pray that someone releases an new product that allows me to pick and choose
    what features I want to include in my app and how I want to distribute it,
    ie (static vs dynamic linking)

    Not sure what else to say. Thanks for reading .

    Kevin

  2. #2
    Karl E. Peterson Guest

    Re: My view of the world

    Hi Kevin --

    I feel your pain. :-(

    > I have serious doubts of MS's claim that the CLR (20 Mb at least) in size
    > will be easily updated and will remain backward compatible. They haven't
    > really done the backward comptability in the past so why should they start
    > now.


    Exactly. ".NET: It's About Trust!" How much do you have? Mine's gone, fwiw.

    > For the sake of my commercial apps I am left with some choices and I would
    > hope that y'all might offer some other insight.
    >
    > 1. Move to .Net, continue the learning cycle of VB.Net and hope that MS deals
    > with the CLR correctly.
    > 2. Move to Delphi and learn another language


    I have trouble with these being two different choices. Seems to me that nearly
    everyone, except those in Redmond, agrees that moving to .NET *is* learning a
    language. The trouble with moving to VFred is that it is close enough, in many
    cases, to Classic VB that you're potentially gonna go crazy with the mindgames it
    will play on you. You've no doubt found many instances where identical code produces
    different results, or where previously valid designs now execute in random order.
    Yes, learn a new language. Just be sure what you already know doesn't get in the
    way!

    > 4. Pray that someone releases an new product that allows me to pick and choose
    > what features I want to include in my app and how I want to distribute it,
    > ie (static vs dynamic linking)


    Well, Borland is heading in a direction where one sourcebase will allow you to
    compile to Win32, Linux, Java, and eventually .NET -- that seems like maximal
    leverage to me. There's also a conversion tool for existing VB source that works
    *far* better (as I'm told) than the one that ships with VS7. Heh, but as we've taken
    to saying around here, "Your Suckage May Vary." ;-)

    Later... Karl
    --
    [Microsoft Basic: 1976-2001, RIP]


  3. #3
    Kevin Moore Guest

    Re: My view of the world


    Karl,

    Thanks for you response. Honestly I was hoping to get some feedback from
    yourself and Zane. The two of you seem to respond to posts in this newsgroup
    in a reasonable nature. Unlike the rest that seem to get caught up in the
    tastes great vs less filling type arguments.

    The funny thing is that my prospective clients for my commercial app always
    ask about technology. Up until now I'll answer MS written in VB and using
    SQL and they'll nod and agree. Not because they no anything but because the
    media and the marketing muscle around the world has told them, similar to
    IBM in the 70's, noone ever lost their job buying MS. I feel cauget between
    a rock and a hardplace. If I migrate to .NET I will be forcing my apps direction
    to be dictated by the folks at MS. If I go with a Borland or other technology,
    than I'll get the inevitable "Who's that" from my client and I feel that
    it could affect my prospective clients buying habits (all other things being
    equal).

    Know anyone that wants to work on a project to write a VB like language and
    take advantage of the seemingly obvious opportunity to fill a void that MS
    has left? <bg>

    Kevin

    "Karl E. Peterson" <karl@mvps.org> wrote:
    >Hi Kevin --
    >
    >I feel your pain. :-(
    >
    >> I have serious doubts of MS's claim that the CLR (20 Mb at least) in size
    >> will be easily updated and will remain backward compatible. They haven't
    >> really done the backward comptability in the past so why should they start
    >> now.

    >
    >Exactly. ".NET: It's About Trust!" How much do you have? Mine's gone,

    fwiw.
    >
    >> For the sake of my commercial apps I am left with some choices and I would
    >> hope that y'all might offer some other insight.
    >>
    >> 1. Move to .Net, continue the learning cycle of VB.Net and hope that MS

    deals
    >> with the CLR correctly.
    >> 2. Move to Delphi and learn another language

    >
    >I have trouble with these being two different choices. Seems to me that

    nearly
    >everyone, except those in Redmond, agrees that moving to .NET *is* learning

    a
    >language. The trouble with moving to VFred is that it is close enough,

    in many
    >cases, to Classic VB that you're potentially gonna go crazy with the mindgames

    it
    >will play on you. You've no doubt found many instances where identical

    code produces
    >different results, or where previously valid designs now execute in random

    order.
    >Yes, learn a new language. Just be sure what you already know doesn't get

    in the
    >way!
    >
    >> 4. Pray that someone releases an new product that allows me to pick and

    choose
    >> what features I want to include in my app and how I want to distribute

    it,
    >> ie (static vs dynamic linking)

    >
    >Well, Borland is heading in a direction where one sourcebase will allow

    you to
    >compile to Win32, Linux, Java, and eventually .NET -- that seems like maximal
    >leverage to me. There's also a conversion tool for existing VB source that

    works
    >*far* better (as I'm told) than the one that ships with VS7. Heh, but as

    we've taken
    >to saying around here, "Your Suckage May Vary." ;-)
    >
    >Later... Karl
    >--
    >[Microsoft Basic: 1976-2001, RIP]
    >



  4. #4
    Mike Mitchell Guest

    Re: My view of the world

    On 15 Feb 2002 16:18:26 -0800, "Kevin Moore" <Kevin@MooreSSI.com>
    wrote:

    Kevin, your posting will really open up a hornet's nest, I believe,
    because this ng is largely the baliwick of evagelists for .NET and all
    things Microsoft, but I'm going to take a back seat on this one and
    let some of the others persuade you to go one way or another.

    Briefly, before I unfold the dickey seat and take my place on the
    sidelines, what I would do, depending on the kind of commercial apps
    you produce, is plan to forget Windows long term. I read several trade
    newspapers in the UK and it's obvious that more and more companies are
    looking (desperately, it has to be said) at alternatives to Windows.
    The obvious choice has to be Linux (mainly because it's about the
    *only* choice apart from Apple). Linux reigns supreme in the server
    world, but still has a long way to go in the desktop application
    market. One thing Linux is crying out for is well-designed,
    well-crafted, easily installed applications of all kinds. Your apps,
    ported to Linux, e.g. using Kylix, which is compatible with Delphi 6,
    *could* possibly be the fuse that helps to set the Linux desktop world
    alight!. You could be in there at the ground floor as the lift starts
    its inevitable rise to the top.

    MM

  5. #5
    Karl E. Peterson Guest

    Re: My view of the world

    Hi Kevin --

    > Thanks for you response. Honestly I was hoping to get some feedback from
    > yourself and Zane. The two of you seem to respond to posts in this newsgroup
    > in a reasonable nature. Unlike the rest that seem to get caught up in the
    > tastes great vs less filling type arguments.


    Much appreciated. Zane will likely disagree with me on this score, but I'm sure
    he'll appreciate hearing that as much as I did regardless.

    > The funny thing is that my prospective clients for my commercial app always
    > ask about technology. Up until now I'll answer MS written in VB and using
    > SQL and they'll nod and agree. Not because they no anything but because the
    > media and the marketing muscle around the world has told them, similar to
    > IBM in the 70's, noone ever lost their job buying MS.


    I think that's changing, and somewhat rapidly. Just as it dawned on folks in the
    late-80s/early-90s that perhaps IBM wasn't operating in *their* best interests, the
    same is happening now with Microsoft. Do I really need to go beyond mentioning the
    self-destruct mechanisms in their latest OS and Office packages to convince you
    (rhetorical you) of that? I defended them relentlessly during the DOJ scandal, but
    right after they seemed to come out of that, there was one revelation after another
    of (what I considered) consumer abuse. That was embarrassing.

    > I feel cauget between a rock and a hardplace.


    Yep.

    > If I migrate to .NET I will be forcing my apps direction
    > to be dictated by the folks at MS. If I go with a Borland or other technology,
    > than I'll get the inevitable "Who's that" from my client and I feel that
    > it could affect my prospective clients buying habits (all other things being
    > equal).


    Well, if Borland call pull off what they suggest they want to do, you can still
    answer ".NET" and folks needn't know the gritty details. <g> ****, I really like
    their full story, though! Having a single sourcebase compilable to Win32 and/or
    Linux is enough for me! If/when .net becomes acceptable, yeah okay, flip that switch
    too. It's about the best leverage anyone is offering today. Vapor, to be sure,
    still, but definitely something to keep an eye on. I guess what I'm really saying is
    that you don't really need to feel a rush right now. I'd just tell clients that the
    jury's still out.

    > Know anyone that wants to work on a project to write a VB like language and
    > take advantage of the seemingly obvious opportunity to fill a void that MS
    > has left? <bg>


    Don't I wish. <g>

    Good luck... Karl
    --
    [Microsoft Basic: 1976-2001, RIP]


  6. #6
    Patrick Troughton Guest

    Re: My view of the world


    Hi Kevin,

    If I may ask a couple follow-up questions...

    Your primary concerns are...

    - Lack of static linking
    - Future versions of the .NET Framework might not be backward compatible

    Is that correct? Is there anything else you consider to be a potential showstopper
    that you're worried about? Also, how do you currently distribute your application
    (CD, internet, etc.)?

    /Pat

    "Kevin Moore" <Kevin@MooreSSI.com> wrote:
    >
    >Hi,
    >
    >I just wanted to get up on my soap box and offer some insight into my world
    >and hopefully get some feedback from y'all. I have been developing app for
    >the last 12 years, the last 6 of which has been predominantly with MS technologies
    >focusing on VB and SQL. I split my time between consulting to clients and
    >developing commercial apps. For my commercial app I use VB (6) and SQL 7/2000
    >and have been doing so for several years. For my consulting I use C++, COM+,
    >ASP or whatever the client chooses.
    >
    >Now onto the rant. Within the scope of my commercial app, I chose VB because
    >it was simply one of the best RAD tools on the market, I could accomplish
    >all of my goals, quickly and easily and I was able to migrate through the
    >various release moving from VB3 -> VB4 -> VB5 to finally VB6. Along the

    way
    >I enjoyed taking advantage of newer technologies that MS has implemented
    >with the language, eg VB5 native compiler and VB6 COM+ integration, VB4

    classes
    >(ok not really due to the problems, but close). Now I come to .Net and I
    >must say from my commercial app point of view I am quite disappointed. Just
    >to clarify I have been working with .Net Beta 2 since last Sept. When I

    first
    >heard about .Net I was hoping that MS would go the way of Delphi in offering
    >Static linking and remove us from the dependecy on MSVBVMx.DLL, when I heard
    >about the CLR I was initially pessimistic. Over the time my pessimism has
    >turned to downright frustration.
    >
    >I have serious doubts of MS's claim that the CLR (20 Mb at least) in size
    >will be easily updated and will remain backward compatible. They haven't
    >really done the backward comptability in the past so why should they start
    >now.
    >
    >For the sake of my commercial apps I am left with some choices and I would
    >hope that y'all might offer some other insight.
    >
    >1. Move to .Net, continue the learning cycle of VB.Net and hope that MS

    deals
    >with the CLR correctly.
    >2. Move to Delphi and learn another language
    >3. Stay with Classic VB and become antiquated (not really an option)
    >4. Pray that someone releases an new product that allows me to pick and

    choose
    >what features I want to include in my app and how I want to distribute it,
    >ie (static vs dynamic linking)
    >
    >Not sure what else to say. Thanks for reading .
    >
    >Kevin



  7. #7
    Kunle Odutola Guest

    Re: My view of the world


    "Kevin Moore" <Kevin@MooreSSI.com> wrote in message
    news:3c6da552$1@10.1.10.29...
    >
    > Hi,


    <SNIP>

    > For my commercial app I use VB (6) and SQL 7/2000
    > and have been doing so for several years. For my consulting I use C++,

    COM+,
    > ASP or whatever the client chooses.


    OK, you've established that picking up new languages (or dialects) isn't
    likely to be a barrier for you.

    > I have serious doubts of MS's claim that the CLR (20 Mb at least) in size
    > will be easily updated and will remain backward compatible. They haven't
    > really done the backward comptability in the past so why should they start
    > now.


    They haven't seriously done the open standard thing for their development
    tools before as well.....

    > For the sake of my commercial apps I am left with some choices and I would
    > hope that y'all might offer some other insight.
    >
    > 1. Move to .Net, continue the learning cycle of VB.Net and hope that MS

    deals
    > with the CLR correctly.


    I would actually recommend C# and not VB.NET. The are aimed at different
    segments of developer-world and you fit into either camp. But you already
    expressed serious doubts based on past evidence so.....let's scrap this.

    > 2. Move to Delphi and learn another language


    Given Borland's decision to support .NET, if Delphi can be made to spit out
    IL in addition to i386+ code then this would seem to give effortless choices
    in terms of deployment options - ship native executables or IL assemblies .
    Or even ship to Linux.

    > 3. Stay with Classic VB and become antiquated (not really an option)


    You're right that this is [really] only a sensible short-mid term option.

    > 4. Pray that someone releases an new product that allows me to pick and

    choose
    > what features I want to include in my app and how I want to distribute it,
    > ie (static vs dynamic linking)


    No need to pray. Most dev tools allow you to decide what features to include
    in your app - can't remember a tool that forced me to have a GUI in my
    console app <g>. So distribution/deplyment options seems to be the crux for
    you.

    Well, for my money in terms of offering what you feel you need (static vs
    dynamic linking):
    a) C++ already offers that option. But your productivity will likely take a
    dive. And there is no code migration support.
    b) There is _talk_ that C# might be added gcc's list of front-ends - with a
    view to producing native code - but I see no concrete signs of that yet. And
    there is no code migration support. Actually this is untrue, decompilers can
    produce C# source from your VB.NET assemblies for you ;-)
    c) You could write in Java and use ArtInSoft's JCLA EE to convert to C#. For
    EVERY release ;-)
    d) VB.NET allows you continue to use most of your VB skills but there is no
    native exe option. Cleanest upgrade path.
    d) Borland promises that Delphi will generate .NET code. IMHO it isn't as
    productive as C# or VB.NET. There are VB2Delphi code conversion tools but,
    if the .NET framework libraries are hidden away behind Delphi's own VCL, I'd
    be wary. It is the most flexible in terms of code deployement options
    though - i386+, .NET or Linux (via Kylix). Assuming Borland can deliver....

    So, what to choose, if "static vs dynamic linking" is a hard requirement
    choose Delphi. If not then flip a coin between C# and VB.NET. Remember,
    VB.NET has a code migration wizard but so does C# ;-)

    Kunle



  8. #8
    Kevin Moore Guest

    Re: My view of the world


    Hi Patrick,

    Thanks for your response. I'll answer your questions inline:

    "Patrick Troughton" <Patrick@Troughton.com> wrote:
    >
    >Hi Kevin,
    >
    >If I may ask a couple follow-up questions...
    >
    >Your primary concerns are...
    >
    >- Lack of static linking


    1. This is really an issue of choice. I am concerned that in the commercial
    app part of my world, I have no choice with distribution strategy for my
    clients. If I use .Net I must distribute with the CLR, no if ands or buts
    about it. I would prefer the ability to choose and implement a strategy that
    is best for myself and my clients. Not one that is determined by people at
    another company.

    >- Future versions of the .NET Framework might not be backward compatible


    2. Basically yes, I have been burned with DLL **** from MS and I have doubts
    that they will deliver on all they promise. I also have issues with this
    strategy, but that relates more so to # 1.

    >
    >Is that correct? Is there anything else you consider to be a potential showstopper


    I didn't mention in my original post, but there are alot of things I like
    about .Net. Most of them have been discussed here, a small list: true OO,
    try/catch and other language improvements.

    >that you're worried about? Also, how do you currently distribute your application


    I currently distrbute the app on CD, so the 20Mb isn't as much of an issue
    for the initial distribution. When a new feature is released though and I
    want to update various client machines, getting them to D/L 20Mb+ for an
    update is a royal pain in the a??. I am also looking at some new web-based
    deployment technologies.

    I guess it all mainly relates to my first answer, choice. I would like to
    choose what is the best for me.

    Thanks for you response. Hopefully you have some comments/suggestions.

    Kevin


    >(CD, internet, etc.)?
    >
    >/Pat
    >
    >"Kevin Moore" <Kevin@MooreSSI.com> wrote:
    >>
    >>Hi,
    >>
    >>I just wanted to get up on my soap box and offer some insight into my world
    >>and hopefully get some feedback from y'all. I have been developing app

    for
    >>the last 12 years, the last 6 of which has been predominantly with MS technologies
    >>focusing on VB and SQL. I split my time between consulting to clients and
    >>developing commercial apps. For my commercial app I use VB (6) and SQL

    7/2000
    >>and have been doing so for several years. For my consulting I use C++,

    COM+,
    >>ASP or whatever the client chooses.
    >>
    >>Now onto the rant. Within the scope of my commercial app, I chose VB because
    >>it was simply one of the best RAD tools on the market, I could accomplish
    >>all of my goals, quickly and easily and I was able to migrate through the
    >>various release moving from VB3 -> VB4 -> VB5 to finally VB6. Along the

    >way
    >>I enjoyed taking advantage of newer technologies that MS has implemented
    >>with the language, eg VB5 native compiler and VB6 COM+ integration, VB4

    >classes
    >>(ok not really due to the problems, but close). Now I come to .Net and

    I
    >>must say from my commercial app point of view I am quite disappointed.

    Just
    >>to clarify I have been working with .Net Beta 2 since last Sept. When I

    >first
    >>heard about .Net I was hoping that MS would go the way of Delphi in offering
    >>Static linking and remove us from the dependecy on MSVBVMx.DLL, when I

    heard
    >>about the CLR I was initially pessimistic. Over the time my pessimism has
    >>turned to downright frustration.
    >>
    >>I have serious doubts of MS's claim that the CLR (20 Mb at least) in size
    >>will be easily updated and will remain backward compatible. They haven't
    >>really done the backward comptability in the past so why should they start
    >>now.
    >>
    >>For the sake of my commercial apps I am left with some choices and I would
    >>hope that y'all might offer some other insight.
    >>
    >>1. Move to .Net, continue the learning cycle of VB.Net and hope that MS

    >deals
    >>with the CLR correctly.
    >>2. Move to Delphi and learn another language
    >>3. Stay with Classic VB and become antiquated (not really an option)
    >>4. Pray that someone releases an new product that allows me to pick and

    >choose
    >>what features I want to include in my app and how I want to distribute

    it,
    >>ie (static vs dynamic linking)
    >>
    >>Not sure what else to say. Thanks for reading .
    >>
    >>Kevin

    >



  9. #9
    Kevin Moore Guest

    Re: My view of the world


    Kunle,

    Thanks for your response. You have made some strong points and I appreciate
    the clarification. I feel that static vs dynamic linking is a pretty big
    issue, but that relates to another issue about choice. I feel that MS has
    predetermined one route and only one route for software development. I am
    not a big fan of being forced to choose, I am also pretty stubborn and find
    some resistance to MS because of this.

    I appreciate your comments about C++, I finished up a year long project integrating
    C++, VB and COM+, it was pretty interesting and a good learning experience.
    I did find that from a productivity point C++ was difficult compared to VB.
    But once I got up to speed on it I became reasonably productive. Part of
    the reason for me staying away from C++ and looking at VB was because of
    the low-level memory manipulatin type stuff. I found it much easier and more
    productive using VB.

    I will have a closer look at C# and possibly look at moving towards it. As
    you mentioned, I have to continue my learning of VB.Net or look at C#.

    Thanks again.

    Kevin


    "Kunle Odutola" <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:
    >
    >"Kevin Moore" <Kevin@MooreSSI.com> wrote in message
    >news:3c6da552$1@10.1.10.29...
    >>
    >> Hi,

    >
    ><SNIP>
    >
    >> For my commercial app I use VB (6) and SQL 7/2000
    >> and have been doing so for several years. For my consulting I use C++,

    >COM+,
    >> ASP or whatever the client chooses.

    >
    >OK, you've established that picking up new languages (or dialects) isn't
    >likely to be a barrier for you.
    >
    >> I have serious doubts of MS's claim that the CLR (20 Mb at least) in size
    >> will be easily updated and will remain backward compatible. They haven't
    >> really done the backward comptability in the past so why should they start
    >> now.

    >
    >They haven't seriously done the open standard thing for their development
    >tools before as well.....
    >
    >> For the sake of my commercial apps I am left with some choices and I would
    >> hope that y'all might offer some other insight.
    >>
    >> 1. Move to .Net, continue the learning cycle of VB.Net and hope that MS

    >deals
    >> with the CLR correctly.

    >
    >I would actually recommend C# and not VB.NET. The are aimed at different
    >segments of developer-world and you fit into either camp. But you already
    >expressed serious doubts based on past evidence so.....let's scrap this.
    >
    >> 2. Move to Delphi and learn another language

    >
    >Given Borland's decision to support .NET, if Delphi can be made to spit

    out
    >IL in addition to i386+ code then this would seem to give effortless choices
    >in terms of deployment options - ship native executables or IL assemblies


  10. #10
    Kunle Odutola Guest

    Re: My view of the world


    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news:3c6dadeb.18621587@news.devx.com...

    > Linux reigns supreme in the server world,


    Only in what passes for your mind Mike.

    Kunle



  11. #11
    Tom Shelton Guest

    Re: My view of the world

    Good thing Perl runs under .NET . Seriously, I love Perl, but it is my
    impression that it is sort of begin replaced in the web world with
    ASP/JSP/PHP. I could be wrong, I haven't had any Perl work for about a year
    now, and that is what is giving me that impression I guess.

    Tom Shelton

    "Michael D. Kersey" <mdkersey@hal-pc.org> wrote in message
    news:3C6DBA09.6C499148@hal-pc.org...
    > Notes inline...
    > Kevin Moore wrote:
    > > Now onto the rant. Within the scope of my commercial app, I chose VB

    because
    > > it was simply one of the best RAD tools on the market, I could

    accomplish
    > > all of my goals, quickly and easily and I was able to migrate through

    the
    > > various release moving from VB3 -> VB4 -> VB5 to finally VB6.

    >
    > You slipped here: the best choice would have been PowerBuilder, which
    > remains the best Windows client/server development tool today.
    >
    > > 1. Move to .Net, continue the learning cycle of VB.Net and hope that MS

    deals
    > > with the CLR correctly.
    > > 2. Move to Delphi and learn another language
    > > 3. Stay with Classic VB and become antiquated (not really an option)
    > > 4. Pray that someone releases an new product that allows me to pick and

    choose
    > > what features I want to include in my app and how I want to distribute

    it,
    > > ie (static vs dynamic linking)

    >
    > If you'll be doing web apps, use Perl (which runs under Windows or Linux
    > or Unix). Perl has everything *today*: web services, XML, SOAP, UDDI,
    > thousands of web and client/server utilities that Microsoft products
    > simply don't have: see the CPAN libraries of tested and thoroughly
    > debugged code at
    > http://www.cpan.org/
    > or better, search to see what's available at
    > http://search.cpan.org/
    >
    > Perl is also used for client/server development: there are Perl/TK
    > libraries in CPAN that are used for C/S development.
    >
    > Perl is undergoing changes today: a new Perl 6, with significant
    > changes, is in the works. Now is a good time to find out what's
    > happening and to get up to speed with a real web language.




  12. #12
    Robert Scoble Guest

    Re: My view of the world

    >is plan to forget Windows long term.

    Interesting you should say this. .NET to me looks like Microsoft's plan for
    the day when we all forget Windows. After all, let's say we all move to OS
    X. All Microsoft has to do is build a CLR for that OS and all our apps will
    move to it.

    But, I don't see Windows going away anytime soon. I have continued to watch
    the Linux market very closely and I just don't see anyone normal moving to
    it (normal being "non technical"). If anything Apple's OS X is stealing even
    some of the die hard Linux fans back. Linux isn't gaining users on the
    desktop and it's arguable whether it's gaining market share on the server
    too. My friends who are analysts are noticing that Linux is losing
    server-side market share too.

    > I read several trade
    > newspapers in the UK and it's obvious that more and more companies are
    > looking (desperately, it has to be said) at alternatives to Windows.


    I'd like to see who's writing these articles. Yes, companies want to get
    away from paying the "Windows Tax" but really, what are the alternatives?
    Linux? Give me a break. The retraining costs alone would outstrip the $100
    you'd save per desktop. Not to mention that Linux needs far more tech
    support per machine and really can't support the wide variety of hardware
    that's already deployed on enterprise desktops. Heck, it's taken Microsoft
    10 years to get NT to do a decent job of supporting all the hardware.

    > The obvious choice has to be Linux (mainly because it's about the
    > *only* choice apart from Apple).


    Actually I'm seeing Apple's OS X making some gains in the corporate world.
    It really is a nice OS. Certainly nicer for a desktop user than any form of
    Linux (and the new PowerBooks have even die-hard VB developers drooling -- I
    was just at breakfast with several of them here at VSLIVE and a few said
    they were considering getting PowerBooks cause they liked the way the
    machines looked and worked).

    >Linux reigns supreme in the server
    > world,


    You live in a different world than I do. Yeah, Linux is used a lot at ISPs
    (Sonic.net, my ISP, for instance, uses Linux exclusively but really, ISPs
    don't serve as platforms for corporate developers and just need a way to
    give users 10MB of server space for an incredibly low cost). But look at the
    corporate market and I don't think you'll see near as many Linux boxes as
    you might expect. Even at UserLand, which does use Linux boxes, they are
    used for just basic Web serving tasks and not as a development platform. So,
    if you are looking at just sheer numbers of boxes deployed you'd be getting
    an incomplete, and misleading, picture.


    >but still has a long way to go in the desktop application
    > market.


    Understatement of the year.

    >One thing Linux is crying out for is well-designed,
    > well-crafted, easily installed applications of all kinds.


    Duh.

    And the corporate types won't invest until at least 50% of the desktops are
    running an OS. Heck, Apple has somewhere around 5 to 10% and it still
    struggles in the corporate world (Apple has many times more corporate
    desktops than Linux does).

    > Your apps,
    > ported to Linux, e.g. using Kylix, which is compatible with Delphi 6,
    > *could* possibly be the fuse that helps to set the Linux desktop world
    > alight!.


    Nope. Corporate apps are the tail. You gotta get the mouth of the dog first.
    How do you get people to push Linux onto desktops? Get them to use Linux at
    home. That means you need killer applications for the home market. I haven't
    seen anything "killer" come out for Linux yet (and, if you've had a chance
    to look at Microsoft's new Tablet computer, coming out next year, you'll
    realize that Linux is gonna be behind in the home market for probably
    forever). When the next "big video game" or "music application" or "digital
    photography application" comes out for Linux (and stays exclusively on Linux
    for 18 months or so) then we can talk. I don't see that happening anytime
    soon.

    Don't think that matters to the corporate market? Bull.

    I saw Windows 95 get deployed at home way before it got deployed in the
    workforce. That's precisely what's happening with Windows XP too. Folks are
    getting it at home and then forcing their IT departments to react "why the
    **** do I have an OS at home that doesn't crash when you're forcing me to
    stick with Windows ME here at work?"

    >You could be in there at the ground floor as the lift starts
    > its inevitable rise to the top.


    Keep dreaming. Actually, if you wanna go anti-Microsoft you should take a
    second look at Mac OS X. It's far superior to Linux for the desktop. Heck,
    look at Doc Searls. He's the Editor of one of those Linux magazines. He
    admitted to me that he uses OS X on a PowerBook and never uses Linux on the
    desktop anymore. http://doc.weblogs.com/

    Robert Scoble

    ###



  13. #13
    Kathleen \(MS MVP\) Guest

    Re: My view of the world

    Karl,

    Well, I got back to town to find I agree and disagree.

    > I have trouble with these being two different choices. Seems to me that

    nearly
    > everyone, except those in Redmond, agrees that moving to .NET *is*

    learning a
    > language.


    Agree. A great new language, btw.

    > You've no doubt found many instances where identical code produces
    > different results, or where previously valid designs now execute in random

    order.

    You know this is what I fought for. Migrated code should fail or produce
    nothing. But I really didn't think we were that far off. I know there are
    tons of places the code won't run, and I know Integer/Long is going to cause
    problems. But where else does the code run and give different results. Head
    games are not good. Also, there are places that events fire differently,
    but where have you heard it is random other than DF?

    Kathleen



  14. #14
    Kathleen \(MS MVP\) Guest

    Re: My view of the world

    Kevin,

    > I have serious doubts of MS's claim that the CLR (20 Mb at least) in size
    > will be easily updated and will remain backward compatible. They haven't
    > really done the backward comptability in the past so why should they start
    > now.


    You are missing the point here. You create your app against a particular CLR
    and mark it as such. If MS screws up the CLR in the next release of it (I
    expect these releases to be fairly slow) you can just let your users
    download both (if something else runs on the new CLR). They are independent,
    with some fairly fancy stuff allowing granularity in what version is used. I
    am with you in thinking that MS is capable of mistakes. I was here in the
    VB4 days. But the one of the good things about .NET is that you are no
    longer wed to a single DLL that you have to trust for backward compatibilty.

    I'll post a separate message about cost that I hope you will read. It is
    partially in response to this, but I want to head a thread with it.

    Kathleen



  15. #15
    Kevin Moore Guest

    Re: My view of the world


    Kathleen,

    I appreciate your response. I do have issues with the CLR and if I mis-understand
    what you are saying please correct me. For example, say I have an app that
    is 4 Mb in size. If I generate my app against V1 of the CLR and distribute
    it, everything is fine, I have a 24 Mb release. MS release a service pack
    to the CLR, lets call it V2, and it corrects a feature I wanted to use. I
    recompile my app against V2 and release the change, but to ensure backward
    compatibility, I have to release the V1 framework and the V2 framework, which
    assuming 20Mb for each CLR, creates an install size of 40 Mb + my 4 Mb app
    size. If my above example is correct, obviously you can see the inherent
    problems with it. For every CLR release I have to update the entire CLR and
    add another 20Mb to my app.

    Kevin

    "Kathleen \(MS MVP\)" <someone@nomail.com> wrote:
    >Kevin,
    >
    >> I have serious doubts of MS's claim that the CLR (20 Mb at least) in size
    >> will be easily updated and will remain backward compatible. They haven't
    >> really done the backward comptability in the past so why should they start
    >> now.

    >
    >You are missing the point here. You create your app against a particular

    CLR
    >and mark it as such. If MS screws up the CLR in the next release of it (I
    >expect these releases to be fairly slow) you can just let your users
    >download both (if something else runs on the new CLR). They are independent,
    >with some fairly fancy stuff allowing granularity in what version is used.

    I
    >am with you in thinking that MS is capable of mistakes. I was here in the
    >VB4 days. But the one of the good things about .NET is that you are no
    >longer wed to a single DLL that you have to trust for backward compatibilty.
    >
    >I'll post a separate message about cost that I hope you will read. It is
    >partially in response to this, but I want to head a thread with it.
    >
    >Kathleen
    >
    >



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center