Vulcan .Net and VO 2.8 - yeah right....
in [Visual Objects]
|
From: Graham McKechnie on 1 Oct 2006 23:47 Ginny, > Not really. Have you tried the refactoring tools in C# with VS 2005? I've > found them really useful for naming things more descriptively, making > fields into properties, and extracting methods into other classes, etc. So > it's automated compiler-assisted redesign and not brute force rewriting. Yes I've tried them, but I haven't found any great need of them, when I'm writing code. They might be very useful in a rewrite or redesign situation though. > Yes, that's the plan except it will be Vulcan and C# once Vulcan is > released. It's VO and C# now and a little bit of C. Sorry that was a typo on my part. I did mean Vulcan and C#. Its a little hard to get used to typing Vulcan, when I've been typing VO for so long. > Not really - just separate projects in the same VS solution. It's not as > clean now without VS to keep everything rebuilt and in sync for me. Yes that was what I meant by a mess to maintain - i.e. separate projects for the same program. I'm a great believer in separate projects in the same solution, but in my case its not the same program, they are different projects because they should be separated, even if one does depend on the other. A good example is code that is common code, that is used in both a compact frame work project, say pda version and smartphone version and a desktop project. Multiple platforms - sharing projects or dll's > No they won't, but they won't have to learn the entire Framework on Day > One either. And the grunt work of moving the code and just getting it to > compile will be automated as much as possible. Ok the grut work is now done - but look at what it has produced and they don't understand a line of it, it's not VO, it's not C#, what is it? Its Vulcan. Now where do you buy a book on this new language called Vulcan? Ginny, if you don't know the framework, you aren't going anywhere, with whatever language you choose. Therefore, Day Two will be learn the framework. Guess what they do on Day 3? > I'd never advocate doing nothing and just waiting. I've been trying to get > VO developers interested in learning .NET for 5 years or so now. If > anybody missed my earlier messages Its a pity, but I think you can safely assume that they haven't taken heed on your messages. It was bloody good advice, you convinced me. See it's really all your fault that I left....<g> > I agree with you that designing forms is nice in Visual Studio. Since you > haven't seen Vulcan you may not be aware that the Vulcan Visual Studio > package uses the same VS tools to build the same Windows.Forms forms. It > just generates Vulcan code instead of C# or VB. So you're not giving > anything up there if you decide you want .NET forms. No I haven't seen or used Vulcan, but I did presume it would do the same as any other language running in MS's IDE. I'm presuming that something like Delphi (or whatever its called these days) does it that way too. After all you only have to generate a form in C++ in VS2005 to see those similarities. > I don't really see it that way. For one thing, C# code and Vulcan code can > look very, very similar. I agree with that from the Vulcan code that I have been shown. But I understood what I was looking at because I already knew the code of the classes. That is not going to be the case for a VOer, because I repeat he/she doesn't know the framework. To sum up, I think and I think you also agree, that Voers are screwed until that get down and dirty and learn the framework - no ifs or buts... Graham "Ginny Caughey" <ginny.caughey.online(a)wasteworks.com> wrote in message news:4ob6rrFdr0ieU1(a)individual.net... > Hi Graham, > >>>But if VB 6 or VO developers want to use a compatibility library for some >>>code for a while, I can see the value of that. >> >> That doesn't sound good for VOers bundling them into the same class as >> the VBers. The VB stuff in .Net is just an excuse for the VBers. If they >> need a compatability layer, I think that says something.... is that >> another bandaid? > > Yes it's a Bandaid, but Bandaids have their uses too, especially for > short-term use. > >> You don't really see that much VB stuff in .Net these days. Well I don't, >> because if a question starts with VB .Net code I just skip it. It always >> was a terrible language and I don't think its got any better with its >> move to .Net, just more verbose. Just reading that stuff is enough to put >> any one off. > > I think you know that VB isn't my favorite language either, but I do make > the effort to read it occasionally if it's part of an interesting question > or sample. I do draw the line at writing it though. <g> > >>>I see Vulcan as a way to move a lot of code quickly to .NET, then >>>gradually extend that in the .NET language of my choice, refactoring as I >>>am able to do so. >> >> Interesting choice of words - refactor. Just a fancy MS term for the >> other dreaded word - "rewrite". > > Not really. Have you tried the refactoring tools in C# with VS 2005? I've > found them really useful for naming things more descriptively, making > fields into properties, and extracting methods into other classes, etc. So > it's automated compiler-assisted redesign and not brute force rewriting. > I'm sure I'll want to turn those types of tools onto my > VO-migrated-to-.NET code once I'm able to, but as you may also remember > from your VO days, the VO IDE doesn't have those sorts of refactoring > tools itself so for now that has to wait. > >> So by your own admission, we can conclude that there will be quite a lot >> of re writing going on in your code in the future. > > There's always an amount of rewriting going on in my VO code today - > that's just part of what I have to do to keep customers all over North > America happy. I don't see that changing, although I do see the tools and > languages I use continuing to evolve. > > So I guess you are going to >> use a combination of VO and C# > > Yes, that's the plan except it will be Vulcan and C# once Vulcan is > released. It's VO and C# now and a little bit of C. > > - sounds like one hell of a comprimise and a >> mess to maintain. > > Not really - just separate projects in the same VS solution. It's not as > clean now without VS to keep everything rebuilt and in sync for me. > > Overtime it may work
From: Paul D B on 2 Oct 2006 03:32 Brian, Brian wrote: > > I can only tell you that we have NOT been deaf on this issue, and > that new VOPS plans will be announced in the future that will provide > varying levels of support. Some things just take time to implement. Good, I'm looking forward to it. > > VOPS will continue to operate after > Vulcan.NET is shipping. >> Will the price go down? That would be the logical consequence. > > Probably not. but I feel that is not very correct. Getting a copy of Vulcan was part of the package and partly a justification for the price, so once Vulcan is delivered that argument no longers stands. >> > PS. I really enjoyed your link to http://www.pakin.org/complaint you're welcome (remember the link... might come in handy one day (if you want to annoy your taxman or so) ) > The writing style reminds me of a certain poster name Illias. Oh yes. Whatever happened to Ilias? I don't think he used Pakins "Complaint generator", but he had something similar built into his brain I guess. - Paul
From: Ginny Caughey on 2 Oct 2006 08:01 Graham, >> Not really - just separate projects in the same VS solution. It's not as >> clean now without VS to keep everything rebuilt and in sync for me. > > Yes that was what I meant by a mess to maintain - i.e. separate projects > for the same program. I'm a great believer in separate projects in the > same solution, but in my case its not the same program, they are different > projects because they should be separated, even if one does depend on the > other. A good example is code that is common code, that is used in both a > compact frame work project, say pda version and smartphone version and a > desktop project. Multiple platforms - sharing projects or dll's I do this flavor as well of course, and since code from different languages needs to be built into different DLLs, it's sort of the same thing for me. Practically speaking, I might end up with a C# GUI project, a Vulcan GUI project, and a couple of libraries built with one or the other - not that much to keep straight. My VS solution with the largest number of projects currently is where I have several different utilities for changing data from one format to another (SQL Server, SQL Everywhere, DBF) and I have common code that defines data structures, etc. with separate pieces for data access The DBF-access pieces reference one VO-built DLL that I have to make sure I keep built in sync manually, and it will be nice when it's a Vulcan DLL instead and VS can do that for me. Fortunately I don't change that DLL often. > Ok the grut work is now done - but look at what it has produced and they > don't understand a line of it, it's not VO, it's not C#, what is it? It's mainly VO. Classes will end with END CLASS and you can declare variables anywhere in a method up to the point where you use them (finally!) and a few things like that, but VO developers won't have trouble reading it. > Vulcan. Now where do you buy a book on this new language called Vulcan? Somebody at Grafx is working on that already I believe. But it's really just the VO language plus enhancements and without PRIVATE and PUBLIC. The language sections concerning What's Different and What's New will be far more interesting to VO developers than the sections about What's the Same. >> I'd never advocate doing nothing and just waiting. I've been trying to >> get VO developers interested in learning .NET for 5 years or so now. If >> anybody missed my earlier messages > > Its a pity, but I think you can safely assume that they haven't taken heed > on your messages. It was bloody good advice, you convinced me. See it's > really all your fault that I left....<g> Heh. <g> I think I may have convinced others as well, although my message has never been to leave VO but instead of add C#. At a recent conference in the Netherlands I asked how many of the VO attendees in my session were at least somewhat familar with C# (to see if they could understand my samples) and about 3/4 of them were. As you yourself have pointed out, C# isn't a big stretch for a VO developer - it's the Framework that takes a little while to learn. And that's where the Vulcan compatibility library eases the transition for both the existing code that gets migrated as well as for the developer. >> I don't really see it that way. For one thing, C# code and Vulcan code >> can look very, very similar. > > I agree with that from the Vulcan code that I have been shown. But I > understood what I was looking at because I already knew the code of the > classes. That is not going to be the case for a VOer, because I repeat > he/she doesn't know the framework. The classes and methods are generally sensibly named and are pretty easy to read for newcomers. They're a bit harder to write until they learn them although Intellisense helps out a lot. > To sum up, I think and I think you also agree, that Voers are screwed > until that get down and dirty and learn the framework - no ifs or buts... I wouldn't say they're screwed - only that they're limited to working at the compatibility layer. Ginny > > Graham > > > "Ginny Caughey" <ginny.caughey.online(a)wasteworks.com> wrote in message > news:4ob6rrFdr0ieU1(a)individual.net... >> Hi Graham, >> >>>>But if VB 6 or VO developers want to use a compatibility library for >>>>some code for a while, I can see the value of that. >>> >>> That doesn't sound good for VOers bundling them into the same class as >>> the VBers. The VB stuff in .Net is just an excuse for the VBers. If they >>> need a compatability layer, I think that says something.... is that >>> another bandaid? >> >> Yes it's a Bandaid, but Bandaids have their uses too, especially for >> short-term use. >> >>> You don't really see that much VB stuff in .Net these days. Well I >>> don't, because if a question starts with VB .Net code I just skip it. It >>> always was a terrible language and I don't think its got any better with >>> its move to .Net, just more verbose. Just reading that stuff is enough >>> to put any one off. >> >> I think you know that VB isn't my favorite language either, but I do make >> the effort to read it occasionally if it's part of an interesting >> question or sample. I do draw the line at writing it though. <g> >> >>>>I see Vulcan as a way to move a lot of code quickly to .NET, then >>>>gradually extend that in the .NET language of my choice, refactoring as >>>>I am able to do so. >>> >>> Interesting choice of words - refactor. Just a fancy MS term for the >>> other dreaded word - "rewrite". >> >> Not really. Have you tried the refactoring tools in C# with VS 2005? I've >> found them really useful for naming things more descriptively, making >> fields into properties, and extracting methods into other classes, etc. >> So it's automated compiler-assisted redesign and not brute force >> rewriting. I'm sure I'll want to turn those types of tools onto my >> VO-migrated-to-.NET code once I'm able to, but as you may also remember >> from your VO days, the VO IDE doesn't have those sorts of refactoring >> tools itself so for now that has to wait. >> >>> So by your own admission, we can conclude that there will be quite a lot >>> of re writing going on in your code in the future. >> >> There's always an amount of rewriting going on in my VO code today - >> that's just part of what I have to do
From: Graham McKechnie on 2 Oct 2006 12:19 Ginny, >I think I may have convinced others as well, although my message has never >been to leave VO but instead of add C#. I have the impression that your message has changed somewhat, as compared to what you delivered to me nearly 4 years ago. But don't get me wrong, I've been very happy with the outcome. >>I wouldn't say they're screwed - only that they're limited to working at >>the compatibility layer. Conclusions is what it is all about. I hope those reading can now understand, their task ahead. I think you would also agree a compatibility layer is not going to get them very far in .Net. Graham "Ginny Caughey" <ginny.caughey.online(a)wasteworks.com> wrote in message news:4ocdf4Fe0huuU1(a)individual.net... > Graham, > >>> Not really - just separate projects in the same VS solution. It's not as >>> clean now without VS to keep everything rebuilt and in sync for me. >> >> Yes that was what I meant by a mess to maintain - i.e. separate projects >> for the same program. I'm a great believer in separate projects in the >> same solution, but in my case its not the same program, they are >> different projects because they should be separated, even if one does >> depend on the other. A good example is code that is common code, that is >> used in both a compact frame work project, say pda version and smartphone >> version and a desktop project. Multiple platforms - sharing projects or >> dll's > > I do this flavor as well of course, and since code from different > languages needs to be built into different DLLs, it's sort of the same > thing for me. Practically speaking, I might end up with a C# GUI project, > a Vulcan GUI project, and a couple of libraries built with one or the > other - not that much to keep straight. My VS solution with the largest > number of projects currently is where I have several different utilities > for changing data from one format to another (SQL Server, SQL Everywhere, > DBF) and I have common code that defines data structures, etc. with > separate pieces for data access The DBF-access pieces reference one > VO-built DLL that I have to make sure I keep built in sync manually, and > it will be nice when it's a Vulcan DLL instead and VS can do that for me. > Fortunately I don't change that DLL often. > >> Ok the grut work is now done - but look at what it has produced and they >> don't understand a line of it, it's not VO, it's not C#, what is it? > > It's mainly VO. Classes will end with END CLASS and you can declare > variables anywhere in a method up to the point where you use them > (finally!) and a few things like that, but VO developers won't have > trouble reading it. > >> Vulcan. Now where do you buy a book on this new language called Vulcan? > > Somebody at Grafx is working on that already I believe. But it's really > just the VO language plus enhancements and without PRIVATE and PUBLIC. The > language sections concerning What's Different and What's New will be far > more interesting to VO developers than the sections about What's the Same. > >>> I'd never advocate doing nothing and just waiting. I've been trying to >>> get VO developers interested in learning .NET for 5 years or so now. If >>> anybody missed my earlier messages >> >> Its a pity, but I think you can safely assume that they haven't taken >> heed on your messages. It was bloody good advice, you convinced me. See >> it's really all your fault that I left....<g> > > Heh. <g> I think I may have convinced others as well, although my message > has never been to leave VO but instead of add C#. At a recent conference > in the Netherlands I asked how many of the VO attendees in my session were > at least somewhat familar with C# (to see if they could understand my > samples) and about 3/4 of them were. As you yourself have pointed out, C# > isn't a big stretch for a VO developer - it's the Framework that takes a > little while to learn. And that's where the Vulcan compatibility library > eases the transition for both the existing code that gets migrated as well > as for the developer. > >>> I don't really see it that way. For one thing, C# code and Vulcan code >>> can look very, very similar. >> >> I agree with that from the Vulcan code that I have been shown. But I >> understood what I was looking at because I already knew the code of the >> classes. That is not going to be the case for a VOer, because I repeat >> he/she doesn't know the framework. > > The classes and methods are generally sensibly named and are pretty easy > to read for newcomers. They're a bit harder to write until they learn them > although Intellisense helps out a lot. > >> To sum up, I think and I think you also agree, that Voers are screwed >> until that get down and dirty and learn the framework - no ifs or buts... > > I wouldn't say they're screwed - only that they're limited to working at > the compatibility layer. > > Ginny > >> >> Graham >> >> >> "Ginny Caughey" <ginny.caughey.online(a)wasteworks.com> wrote in message >> news:4ob6rrFdr0ieU1(a)individual.net... >>> Hi Graham, >>> >>>>>But if VB 6 or VO developers want to use a compatibility library for >>>>>some code for a while, I can see the value of that. >>>> >>>> That doesn't sound good for VOers bundling them into the same class as >>>> the VBers. The VB stuff in .Net is just an excuse for the VBers. If >>>> they need a compatability layer, I think that says something.... is >>>> that another bandaid? >>> >>> Yes it's a Bandaid, but Bandaids have their uses too, especially for >>> short-term use. >>> >>>> You don't really see that much VB stuff in .Net these days. Well I >>>> don't, because if a question starts with VB .Net code I just skip it. >>>> It always was a terrible language and I don't think its got any better >>>> with its move to .Net, just more verbose. Just reading that stuff is >>>> enough to put any one off. >>> >>> I think you know that VB isn't my favorite language either, but I do >>> make the effort to read it occasionally if it's part of an interesting >>> question or sample. I do draw the line at writing it though. <g> >>> >>>>>I see Vulcan as a way to move a lot of code quickly to .NET, then >>>>>gradually extend that in the .NET language of my choice, refactoring as >>>>>I am able to do so. >>>> >>>> Interesting choice of words - r
From: Ginny Caughey on 2 Oct 2006 12:52
Graham, A compatibility layer will get them started. Later they'll want to use the Framework classes directly, if the VB community is any example of their use of the VisualBasic compatibility layer. And of course Vulcan deveopers create forms using the Windows.Forms designer, they'll be getting Framework code anyway, so they'll gradually get used to using it. I don't get the sense that VO developers moving to Vulcan would want to avoid the .NET Framework entirely, they just don't want to be overwhelmed with it initially. -- Ginny "Graham McKechnie" <gmknospam(a)bigpond.net.au> wrote in message news:ZZaUg.40226$rP1.13848(a)news-server.bigpond.net.au... > Ginny, > >>I think I may have convinced others as well, although my message has never >>been to leave VO but instead of add C#. > > I have the impression that your message has changed somewhat, as compared > to what you delivered to me nearly 4 years ago. But don't get me wrong, > I've been very happy with the outcome. > >>>I wouldn't say they're screwed - only that they're limited to working at >>>the compatibility layer. > > Conclusions is what it is all about. I hope those reading can now > understand, their task ahead. I think you would also agree a compatibility > layer is not going to get them very far in .Net. > > Graham > > > > "Ginny Caughey" <ginny.caughey.online(a)wasteworks.com> wrote in message > news:4ocdf4Fe0huuU1(a)individual.net... >> Graham, >> >>>> Not really - just separate projects in the same VS solution. It's not >>>> as clean now without VS to keep everything rebuilt and in sync for me. >>> >>> Yes that was what I meant by a mess to maintain - i.e. separate >>> projects for the same program. I'm a great believer in separate projects >>> in the same solution, but in my case its not the same program, they are >>> different projects because they should be separated, even if one does >>> depend on the other. A good example is code that is common code, that is >>> used in both a compact frame work project, say pda version and >>> smartphone version and a desktop project. Multiple platforms - sharing >>> projects or dll's >> >> I do this flavor as well of course, and since code from different >> languages needs to be built into different DLLs, it's sort of the same >> thing for me. Practically speaking, I might end up with a C# GUI project, >> a Vulcan GUI project, and a couple of libraries built with one or the >> other - not that much to keep straight. My VS solution with the largest >> number of projects currently is where I have several different utilities >> for changing data from one format to another (SQL Server, SQL Everywhere, >> DBF) and I have common code that defines data structures, etc. with >> separate pieces for data access The DBF-access pieces reference one >> VO-built DLL that I have to make sure I keep built in sync manually, and >> it will be nice when it's a Vulcan DLL instead and VS can do that for me. >> Fortunately I don't change that DLL often. >> >>> Ok the grut work is now done - but look at what it has produced and they >>> don't understand a line of it, it's not VO, it's not C#, what is it? >> >> It's mainly VO. Classes will end with END CLASS and you can declare >> variables anywhere in a method up to the point where you use them >> (finally!) and a few things like that, but VO developers won't have >> trouble reading it. >> >>> Vulcan. Now where do you buy a book on this new language called Vulcan? >> >> Somebody at Grafx is working on that already I believe. But it's really >> just the VO language plus enhancements and without PRIVATE and PUBLIC. >> The language sections concerning What's Different and What's New will be >> far more interesting to VO developers than the sections about What's the >> Same. >> >>>> I'd never advocate doing nothing and just waiting. I've been trying to >>>> get VO developers interested in learning .NET for 5 years or so now. If >>>> anybody missed my earlier messages >>> >>> Its a pity, but I think you can safely assume that they haven't taken >>> heed on your messages. It was bloody good advice, you convinced me. See >>> it's really all your fault that I left....<g> >> >> Heh. <g> I think I may have convinced others as well, although my message >> has never been to leave VO but instead of add C#. At a recent conference >> in the Netherlands I asked how many of the VO attendees in my session >> were at least somewhat familar with C# (to see if they could understand >> my samples) and about 3/4 of them were. As you yourself have pointed out, >> C# isn't a big stretch for a VO developer - it's the Framework that takes >> a little while to learn. And that's where the Vulcan compatibility >> library eases the transition for both the existing code that gets >> migrated as well as for the developer. >> >>>> I don't really see it that way. For one thing, C# code and Vulcan code >>>> can look very, very similar. >>> >>> I agree with that from the Vulcan code that I have been shown. But I >>> understood what I was looking at because I already knew the code of the >>> classes. That is not going to be the case for a VOer, because I repeat >>> he/she doesn't know the framework. >> >> The classes and methods are generally sensibly named and are pretty easy >> to read for newcomers. They're a bit harder to write until they learn >> them although Intellisense helps out a lot. >> >>> To sum up, I think and I think you also agree, that Voers are screwed >>> until that get down and dirty and learn the framework - no ifs or >>> buts... >> >> I wouldn't say they're screwed - only that they're limited to working at >> the compatibility layer. >> >> Ginny >> >>> >>> Graham >>> >>> >>> "Ginny Caughey" <ginny.caughey.online(a)wasteworks.com> wrote in message >>> news:4ob6rrFdr0ieU1(a)individual.net... >>>> Hi Graham, >>>> >>>>>>But if VB 6 or VO developers want to use a compatibility library for >>>>>>some code for a while, I can see the value of that. >>>>> >>>>> That doesn't sound good for VOers bundling them into the same class as >>>>> the VBers. The VB stuff in .Net is just an excuse for the VBers. If >>>>> they need a compatability layer, I think that says something.... is >>>>> that another bandaid? >>>> >>>> Yes it's a Bandaid, but Bandaids have their uses too, especia |