I'm a bit of a radical when it comes to business logic.
I believe it belongs in SPROCS in the database.
...
That's great if you have access to the database. I can also imagine it keeps things nice and tidy with a single 'go to' place when business needs change.
Unfortunately, some of us work in an IT world where they think that the database is 'theirs' and no one should meddle with it - the only reason it exists is to support the business process. Mordac, the preventer of information services would be proud.
"Ok, my response to that is pending a Google search" - Bucky Katt. "There are two types of people in the world: Those who can extrapolate from incomplete data sets." - Unk. "Before you can 'think outside the box' you need to understand where the box is."
That's great if you have access to the database. I can also imagine it keeps things nice and tidy with a single 'go to' place when business needs change.
Unfortunately, some of us work in an IT world where they think that the database is 'theirs' and no one should meddle with it - the only reason it exists is to support the business process. Mordac, the preventer of information services would be proud.
That is sad - I'm a DB junkie - they can't take it away from me!!
I use agile development methods - I need to do 50% of the db, 50% of the UI - show the client - THEY ARE going to ask for CHANGES - do another 20% - show more - another 20% - never done - that's what maintenance is for!
Not sure how a VB6 design time database connection would make that any better (as Dil suggested all true VB6er's must do).
*** Read the sticky in the DB forum about how to get your question answered quickly!! ***
Please remember to rate posts! Rate any post you find helpful - even in old threads! Use the link to the left - "Rate this Post".
The edit form is slightly complicated, but only in that it has two stored procedures - the load and the update....
It looks very clsoe to teh add form:
Now we have a table, we can add records and edit them.
Next step is to create the list of students.
that belongs to a data list:
Code:
<DataListspec
Id="{guid value}"
Name="Student listing"
Description="Lists all students in the system."
Developer="TG"
>
<SPDataList SPName="USP_STUDENT_DATALIST">
<CreateProcedureSQL>
<![CDATA[
create procedure dbo.USP_STUDENT_DATALIST
as
set nocount on;
select
ID,
STUDENTID,
FNAME,
LNAME,
....
from dbo.STUDENTS
]]>
</CreateProcedureSQL>
</SPDataList>
<!-- define the output fields in the list -->
<Output>
<OutputFields>
<OutputField FieldID="ID" Caption="ID" DataType="Guid" IsHidden="true" />
<OutputField FieldID="STUDENTID" Caption="Student number" DataType="String" />
<OutputField FieldID="FNAME" Caption="First name" DataType="String" />
<OutputField FieldID="LNAME" Caption="Last name" DataType="String" />
</OutputFields>
</Output>
</DataListSpec>
Boom... we now have a list...
Now we create a page that brings it all together:
Code:
<PageSpec
Id="{guid value}"
Name="Students"
Description="Page for maintaining students"
Developer="TG"
>
<Tabs>
<Tab ID="{guid}" Caption="Student list">
<Sections>
<Section ID="{guid}" Caption="Students">
<DataList ID="{guid form the data list spec}" >
<Actions>
<Action ID="{guid}" Caption="Add" ImageKey="res:AddNew">
<ShowAddForm DataFormID="{guid form the add form spec}">
<PostAction>
<RefreshSection />
</PostAction>
</ShowAddForm>
</Action>
<Action ID="{guid}" Caption="Edit" ImageKey="res:edit">
<ShowDataForm DataFormID="{guid form the edit form spec}">
<Context><SectionField>ID</SectionField></Context>
<PostAction>
<RefreshSection />
</PostAction>
</ShowAddForm>
</Action>
</Actions>
</DataList>
</Section>
</Sections>
</Tab>
</Tabs>
</PageSpec>
Now we have a fully functional student CRUD operation well, CRU ... I didn't include the delete operations.
But form all that the platform can built a completely interactive web-based form that allows the suer to see a list, select a student and edit them. Or add a new student.
This obviously shows just a basic, simplistic capability... there's tons more optional stuff - the list can be filtered - the list can auto expand when a student is selected to show student details not in the list (like address, class schedule, etc) and we can even render a field (or two or more) as hyper links that go to another page - so Student ID could be a hyperlink that then goes to a Student Details page.
and in any of the sprocs, they can be as simple or as complicated as needed. I've gone the simple route here just to show the concept. and since the specs are XML-based, they all have schemas in our SDK, which then speeds things up withe intellisense and letting you know what's possible and what isn't (like in the edit form, the load must come before the save sproc.
One of the other powerful things I didn't show was that on these forms, we can link them to UIModel components - this gives us the server side ability to perform logic if needed... as well as creates an HTML file if we need to control the form layout specifically (like putting Fname and LName on the same line instead of in a vertical format). the UIModel then gives me the same capabilities as if I was on a winform client side... so I can enable, disable fields, perform business logic, etc... and it all runs on the server. the platform takes care of the js wiring to make the service calls when it needs to.
That's great if you have access to the database. I can also imagine it keeps things nice and tidy with a single 'go to' place when business needs change.
Unfortunately, some of us work in an IT world where they think that the database is 'theirs' and no one should meddle with it - the only reason it exists is to support the business process. Mordac, the preventer of information services would be proud.
fortunately our clients are usually... well, IT isn't often their priority - they're non-profits, so we don't usually run into that, but then again, the fact that thigns are in the database the way they are in our case, they know full well that's how it works.
Originally Posted by szlamany
@tg - very nice - that is DRY'er then mine.
I live in the nuts and bolts of my meta data. I've considered that I could abstract away further - just no time.
Ever since I cut my teeth on .NEt, I'd been thinking that it would be nice to build custom screens using XML meta data... at the time I wasn't in a place that was receptive to making the investment to making such a change... then I moved on... still, I mulled it over... then I got where I am now... and they had already figured it out! And it even started off as client-rich winforms app... the web-based client didn't come around until a few years ago. Even then, it wasn't until 2012 that we went full tilt web-based and no longer support the winforms version of the product.
Oh... and the page spec also has an AlterPage section... have a client that wants to make Last Name clickable instead of the Student ID? Create a new datalist, then alter page, swaping out one data list for the otehr (<ReplaceDataList OldDataListId=".." NewDataListID=".." /> -- it's that simple).
I use agile development methods - I need to do 50% of the db, 50% of the UI - show the client - THEY ARE going to ask for CHANGES - do another 20% - show more - another 20% - never done - that's what maintenance is for!
Not sure how a VB6 design time database connection would make that any better (as Dil suggested all true VB6er's must do).
agile development:
Euphemism.
Repeatedly throwing code at the wall until it sort of sticks. When it slides off the wall again blame the user, then throw some more.
Bonus: though nothing ever gets completed and the product at any time is usually a Rube Goldberg Machine and is impossible to maintain... you can use semi-skilled coders and the cabal of involved users are supportive because they "got to be involved instead of doing my boring real job."
A win for those involved and a huge loss for the organization.
Right... like the waterfall method is any better. No thanks.
That said, agile can only really work if you get buy in from all the stakeholders at all levels... which rarely happens... when ends up with stake holders, and pitch fork holders, and torches and villagers storming the castle walls.
Repeatedly throwing code at the wall until it sort of sticks. When it slides off the wall again blame the user, then throw some more.
Bonus: though nothing ever gets completed and the product at any time is usually a Rube Goldberg Machine and is impossible to maintain... you can use semi-skilled coders and the cabal of involved users are supportive because they "got to be involved instead of doing my boring real job."
A win for those involved and a huge loss for the organization.
I'm just kind of ignoring dilettante at the moment. We've butted heads in the past, and I was needlessly mean to VB6 back then. I feel like now I can learn a lot from a VB6 developer, but it looks like he's still pretty firm that nothing relevant's happened in software engineering since 1999. I'm really struggling to not say some mean things about that, but it's just not productive.
That DB UI system's pretty slick, by the way! I'm going to keep it in mind if I end up falling into that kind of job.
Last edited by Sitten Spynne; Aug 21st, 2015 at 05:50 PM.
This answer is wrong. You should be using TableAdapter and Dictionaries instead.
Right... like the waterfall method is any better. No thanks.
There is no waterfall method. That's a straw man used by people trying to market patent-medicine methodologies and people trying to excuse undisciplined development practices. Sadly some organizations actually have adopted a weird, faux "waterfall method" though.
It all comes down to managing expectations - feature-creep is a by-product of unmanaged expectations. Which leads to deadlines being missed and no income left to fund the final efforts.
Which was the whole point of the past dozen or so threads - how to be RAD.
Does anyone have a methodology that they feel makes them more RAD? Regardless of VB6 - just in general. We can bring it back to VB6 after we get some more info.
*** Read the sticky in the DB forum about how to get your question answered quickly!! ***
Please remember to rate posts! Rate any post you find helpful - even in old threads! Use the link to the left - "Rate this Post".
I'd sure like some opinions on RAD. I never read a lot about either RAD or agile processes formally, but absorbed a lot of agile while reading about testable designs.
From the scant resources I found, RAD:
Emphasizes stakeholder involvement as early as possible.
Values fast prototyping and iterations over up-front design.
Handles uncertainty by presenting best-guess, low-infrastructure prototypes and soliciting feedback.
Refactors prototypes towards better architectures when uncertainty is low.
That's... hard for me to distinguish from "agile". Scrum just bolts on an estimation style to those same concerns. TDD asserts that the best way to prototype is to start with tests as a specification for known required behaviors. Those all feel like they could nestle snugly into the high-level overview of RAD. Maybe, in this sense, "agile" is a container for patterns, and RAD is one agile pattern. Sort of like how Presentation Model compares to MVC or MVVM.
But it's hard to talk about RAD when I'm ignorant of what gets you the gold-stamp certificate from a paper mill. I know what kind of things make a "certified TDD" shop and which of those you throw out the window the moment you get your fancy sticker. So what's the skinny on RAD? What's the book say you do vs. what real developers do? What's it do well that other processes don't? What's it do badly that other processes do? If VB6 is a "RAD language" and VB .NET is not, what's the distinguishing factors?
This answer is wrong. You should be using TableAdapter and Dictionaries instead.
An obscure body in the SK system. The inhabitants call it Earth
Posts
7,957
Re: What if there was a NEW vb6
For me RAD wasn't so much a development paradigm as a language capability. VB, with it's GUI designers, data wizards etc. let you throw together Apps rapidly so it could call itself a RAD tool. When people talked about RAD development I think it was largely double speak for "we chuck something basic together and then keep changing it until it meets the customer's need".
I think Agile is subtly different in that it tried to nail down some good design principles from the start. TDD (later BDD), Regular SCRUMs, Time estimates etc. are all there to try and add some order to the chaos of iterative development. Sadly, most places that say they're doing Agile development don't actually adopt any of those practices and they are, in truth, doing exactly the same as we used to call RAD.
I don't think this is necessarily a bad thing though. Hacking works. It gets product out the door and does so quicker than a front heavy water fall approach does. While many would like to deny it, the best development approach to many projects is probably to dive right in and work until it's done.
To me the best advances over the last couple of decades aren't that we decided to rebrand RAD as Agile but rather that we've advanced the design patterns we use at a small level. We've learned how to get our design to police our work and how to make our code both testable and flexible. We learned how to structure things in a way to allow for refactoring and we learned to refactor safely through automated testing. I don't see Agile as fundamentally different from RAD, we just got better at it.
The best argument against democracy is a five minute conversation with the average voter - Winston Churchill
Hadoop actually sounds more like the way they greet each other in Yorkshire - Inferrd
I have a client that has auditors that watch the development dollars for ongoing projects.
Current contract I have with them has 3 Sprints (covering 52.5, 23.8 and 23.8 percent of the project). Total project was laid out over 275 days so we just took those 3 percentages to mark when each sprint was done.
Development tasks are each brought further along as each sprint completes. Issues such as: you want to discuss all your output/export requirements before ending Sprint 2 so that the final Sprint has all that knowledge going into it. Some business logic SPROCS (like close a contribution receipt to cash) are only running in query development windows. Lots of final wiring of all that in the UI in final sprint.
We are currently stalled in Sprint 3 due to an uncooperative third party software house.
Nice thing is there is enough dollars left in the budget for me to come back and bring it to fruition.
Basically it is all about the dollars - you have to have cash left for the whole game regardless of how hard the end goal is. No good software gets developed in that situation.
Last edited by szlamany; Aug 22nd, 2015 at 11:34 AM.
*** Read the sticky in the DB forum about how to get your question answered quickly!! ***
Please remember to rate posts! Rate any post you find helpful - even in old threads! Use the link to the left - "Rate this Post".
I'd like to talk about the thread's topic: "a new VB6."
And accept the premise that Microsoft won't ever produce one, accept the things Microsoft got right in creating the VS tools for .Net languages, and that .Net languages are already there for anyone who wants to use them...
... but that some people don't want to, and would prefer some alternative.
There could be many motivations for wanting an alternative, but alternatives abound already. So then the question becomes "What do these people want?"
Different people will have different laundry-lists of "wants" but most of these appeal to small groups of people with special needs. For a VB6 successor aside from VB.Net (which is there for the taking) popularity would probably be key. Without broad adoption such an alternative just becomes another one among so many, none of which ever became wildly popular.
Popular means lots of people would use it, and they probably are not going to be advanced users so making it as "approachable" as possible would probably be key. Most of these people are going to be making fairly simple programs to solve simple problems for themselves. They are going to be self-taught. So it probably needs to be possible to get useful results knowing a small fraction of what the language and its tools offer. And it probably needs to be easy to install, most likely without admin rights because a lot of office workers will be using it for simple "stealth IT" sorts of things... like it or not.
This could be a .Net language based on VBA syntax supporting only WinForms and that might make a lot of people happy. Or it might be actual VBA bundled up with one of the Office Forms libraries and the VBA IDE able to "compile" to MS Access MDE-like executables without the Access Runtime. Or it might be something else entirely like a JavaScript-centric toolchain that can create desktop applications.
I focus on these users because that's probably where the action is, i.e. where the lack is being felt most strongly.
Ha you're lucky dilettante, I just chugged a margarita thanks to an excruciatingly painful QA meeting so I'm feeling pretty good and agreeable right now!
Originally Posted by dilettante
I focus on these users because that's probably where the action is, i.e. where the lack is being felt most strongly.
I understand this, and really my only negative response is I'm not sure if that user represents a good revenue stream for a budding new language. It's definitely a niche, but not in the sense of "small cottage industry". I mean it in the sense of "group of people with specific needs that will spend a LOT of money to get something that scratches their itch." Ignoring them is definitely stupid. Catering to them? I'll let someone else put wagers down first.
Add to your list of requirements that this language should run on some form of tablet, with at least some token iOS/Android functionality, and I'll buy the next round.
I think the coolest dang thing about VB6 that no "modern" professional admits is that as a swiss army knife it totally delivered. It's got a Perl-like "make easy things easy, and hard things possible" mentality, without the "Learn this one neat trick that every other developer hates" mentality in most cases. I can be a total Mort and mash buttons like a neanderthal in some wizard and get something that works, that's still amazing in 2015 so getting it done in 199x was like Microsoft producing the Ark of the Covenant. But then, if by some miracle, Mort reads a couple of API books by accident, he suddenly has access to a whole new world like he's Aladdin. She wants to write apps without the wizards, and VB6 has her back despite the sudden shift in gender. And then if, somehow, that developer spends some free time reading COM documentation and doesn't die, VB6 is still there, with a few shady tricks that are pretty easy to internalize. Now we're not dealing with Mort. We're dealing with someone that can finish a project in half the time a C developer can. We could bicker about "bad architecture" but let's face it, architecture's a hard problem and the reason we've got so many languages is we're desperately trying to find out what works, and haven't had enough time to settle on one. If your software's only problem is you're a little worried about architecture you're probably fine.
That's why I couldn't abide Lightswitch. It looked cool, and I think it's showed up in Swift's "playgrounds", but I was really turned off by the fact that at some level of complexity you had to convert it to a "real" .NET language. VB6 never needed to be transformed into C, it showed up and asserted with bravado that C would be dead in its wake. If people had half a brain, that should've happened in terms of Windows clients. I think a key mistake there is assuming the enterprise market has half a brain. MAYBE collectively, but definitely not individually.
Despite my career being in C#, I've always in my heart seen it as "the VB .NET that C developers could tolerate". Except for the VB lambda syntax. That's just horrid.
Anyway, yeah. What you said, but let consumers write their own iOS/Android apps with it. App Wizards a must for that respect. This idea will topple half the App Store market, and I say good riddance. $4.99 a copy for half a year's work? That's a pittance.
Last edited by Sitten Spynne; Aug 24th, 2015 at 07:29 PM.
This answer is wrong. You should be using TableAdapter and Dictionaries instead.
I'd had some hope for Mozilla XUL though even they've abandoned it.
Then Chrome Packaged Apps looked pretty interesting, and that has a "mobile story" as well.
These seem to come in two flavors: packaged and... not packaged. Or perhaps "not packaged" are just "Chrome Apps" that nobody ran the packager against? I haven't followed this through its development and evolution so I'm a but fuzzy there, though I had the idea there are three things: Chrome Apps, Chrome Packaged Apps, and Chrome Packaged Apps that have not yet been packaged for distribution but will run locally. The main divide being online web apps vs. offline local apps?
In other words Chrome Packaged Apps are sorta kinda like Windows HTAs.
It all looks good until you get to the gory details of course. First you have the twin horrors of JavaScript and the HTML5 DOM's 290 levels deep object hierarchy with long-long-long names for so many things. Then you have the tooling: text editors available that can colorize, auto-indent, and auto-complete... for you to bang out HTML, CSS, and script in the dark with.
Can you say not quite Visual Studio? I swear, if these guys saw the VB6 IDE in action they'd break down and cry at "the amazing future."
So that's been an option for some time. However I can see why adoption has been minimal outside the ChromeOS world despite the Chrome browser's (the only run-time infrastructure required) ubiquity today. The tooling is just far too 1985 and well... JavaScript.
Despite my career being in C#, I've always in my heart seen it as "the VB .NET that C developers could tolerate".
I'm not a C# nor VB.NET developer, but that's exactly how I see it. And I strongly believe that it is true - their goal was to attract C and other developers to think they made a new language while in fact, it's just VB.NET under the mask. They've also tricked VB6 developers to think it's just an evolution of it while in fact, it's a whole new platform which is not producing native Windows applications nor has any other connections with Classic VB, except similar syntax.
Last edited by MikiSoft; Aug 25th, 2015 at 02:50 AM.
An obscure body in the SK system. The inhabitants call it Earth
Posts
7,957
Re: What if there was a NEW vb6
I'm not a C# nor VB.NET developer, but that's exactly how I see it. And I strongly believe that it is true - their goal was to attract C and other developers to think they made a new language while in fact, it's just VB.NET under the mask. They've also tricked VB6 developers to think it's just an evolution of it while in fact, it's a whole new platform which is not producing native Windows applications nor has any other connections with Classic VB, except similar syntax.
I'm afraid I disagree on both points.
I think c# may have been "VB.Net that developers could tolerate" 10-15 years ago but the perception has moved on hugely since. C# seems widely respected in it's own right these days. The last company I worked for (GE) was developing AI engines to detect emergent faults on Aeroplanes - pretty serious stuff. Once upon a time they'd probably have chosen C but these days they chose C#. They also did work to optimise deep sea oil fields - C# again. There was also a whole bunch of Java in the mix and cross language communication was handled with thrift.
And I really don't think MS ever tried to trick anyone that VB.Net was anything other than a new platform. They were quite open about it and have been ever since. I understand that some folks weren't happy with that move but I don't think you can portray it as dishonest.
The best argument against democracy is a five minute conversation with the average voter - Winston Churchill
Hadoop actually sounds more like the way they greet each other in Yorkshire - Inferrd
I'm not a C# nor VB.NET developer, but that's exactly how I see it. And I strongly believe that it is true - their goal was to attract C and other developers to think they made a new language while in fact, it's just VB.NET under the mask. They've also tricked VB6 developers to think it's just an evolution of it while in fact, it's a whole new platform which is not producing native Windows applications nor has any other connections with Classic VB, except similar syntax.
Whoa, hold on there.
So the Statement that C# was created to attract C style language developers to .Net is of course true.
To try and imply that C# is basically VB.Net is utterly utterly wrong and your confusing the language with the framework here.
What your ignoring is the fact the .Net framework support more languages than just VB.Net and C# that part of the point of it that you are not bound to one language, and those languages are wholly different.
Also the idea that MS tricked anyone with VB.Net is a complete fallacy also, and comes from the fact you don't like .Net.
Please Mark your Thread "Resolved", if the query is solved & Rate those who have helped you
That right there I think sums up the problems a lot of people have... they think that the framework is the language and the language is the framework when in fact that's not true. there's the BASIC lexicon nearly all of which is in the VB lexicon... and that's still there.... Dim statements... If Then (else/elseif) end If constructs... those are the VB syntax... but System.Io.Path.Exists... that's framework... that's not part of VB. That's just simply a library. I think that's also where people have problems with .NET, navigating the rich framework model.... it can be daunting with all the naespaces, classes, determing what's static, what needs to be instanciated, but eventually you learn. And if you can do it in VB, it's the same framework in C# ... so all you need to do is learn the differences in the syntax and you're mostly there.... System.Io.Path.Exists works the same in both.
And I strongly believe that it is true - their goal was to attract C and other developers to think they made a new language while in fact, it's just VB.NET under the mask.
Well, actually (the canonical engineer phrase!) their goal was to attract Java developers. If you were around during early .NET, there was a big race to convert every example Java application to .NET and advertise how much faster it ran on the .NET platform. I get the feeling C developers aren't impressed by much and don't jump fences often.
It's not even really VB .NET 'under the mask", it's IL. Because that's what VB .NET is under the mask. That's a little nitpicky, but in general you can say "C# and VB .NET can do the same things" and be almost right. There's a small list of frustrating places where they do not overlap, but most of those are syntax sugar rather than actual CLR features.
They've also tricked VB6 developers to think it's just an evolution of it while in fact, it's a whole new platform which is not producing native Windows applications nor has any other connections with Classic VB, except similar syntax.
I haven't seen a tricked VB6 developer yet. Now, I also wonder if "not producing Native Windows applications" is a truthful statement at this point. WinRT is a .NET platform, and as of a couple of years ago MS's mandate is "WinRT support is mandatory for all new APIs." If I follow that dotted line, I could argue that ".NET is the native Windows platform" in a lot of ways. But that feels like something we could go in circles over.
Originally Posted by techgnome
[...]it can be daunting with all the naespaces, classes, determing what's static, what needs to be instanciated, but eventually you learn. And if you can do it in VB, it's the same framework in C# ... so all you need to do is learn the differences in the syntax and you're mostly there.... System.Io.Path.Exists works the same in both.
-tg
I'm reminded of a story I saw once about a person's trip to Paris. They spent a few weeks studying French beforehand, because they didn't want to be a total American Tourist. They sat at a restaurant and, with their dictionary, started to stumble their way through an order. The waiter smiled, and in English helped them with their order. 5 minutes later, at another table, the same waiter was dealing with another tourist. "DO. YOU. HAVE. ENGLISH. MENUS?" The lady subscribed to "loud, slow English is universal". The waiter? "Je ne parle pas anglais."
It takes 0 minutes to read a basic C# program, it's just curly braces and semicolons. It takes 10 minutes to learn about its method declaration syntax, event handler syntax, and a quick overview of its lambda syntax. That's C# in 10 minutes. Take the time to learn it, the people making fun of VB assume you never will. I get a little angry every time I see a post that contains, "I can't read C#". It's really just "write it for me", but the concept is strange. They're so similar, and they use the same libraries, so I've always felt if you can't comprehend even the expression lines of C# I have little confidence you have any grasp of VB.
"Don't want to" is precisely what makes people think poorly of VB devs.
This answer is wrong. You should be using TableAdapter and Dictionaries instead.
I'm reminded of a story I saw once about a person's trip to Paris. They spent a few weeks studying French beforehand, because they didn't want to be a total American Tourist. They sat at a restaurant and, with their dictionary, started to stumble their way through an order. The waiter smiled, and in English helped them with their order. 5 minutes later, at another table, the same waiter was dealing with another tourist. "DO. YOU. HAVE. ENGLISH. MENUS?" The lady subscribed to "loud, slow English is universal". The waiter? "Je ne parle pas anglais."
It takes 0 minutes to read a basic C# program, it's just curly braces and semicolons. It takes 10 minutes to learn about its method declaration syntax, event handler syntax, and a quick overview of its lambda syntax. That's C# in 10 minutes. Take the time to learn it, the people making fun of VB assume you never will. I get a little angry every time I see a post that contains, "I can't read C#". It's really just "write it for me", but the concept is strange. They're so similar, and they use the same libraries, so I've always felt if you can't comprehend even the expression lines of C# I have little confidence you have any grasp of VB.
"Don't want to" is precisely what makes people think poorly of VB devs.
nice story... and yeah, I cringe when I see that "but it's in C#" from posers. At every single interview I've been to since 2006 I've been asked about my VB.NET experience (which was minimal at first) - almost always followed by "What about C#?" My answer has been virtually the same every time: ".NET is .NET is .NET ... because both languages are built on top of the same framework, they differ only in their syntax. Once you know what those syntax differences are, it's not too difficult to switch from one to the other. While more efficient with VB, I can be productive with C#. Only thing that really slows me down is remembering to hit all those curly brackets."
While I've never been asked to write specifically in C#, I can if I need to... and at my current job, it's an option if I want to, even though it's not our shop standard.
I don't get all of this insecurity. If people choose not to use .Net languages that's their choice. I can see a few lines to correct an erroneous statement but this reaction is ridiculous. It also appears to account for almost all of this thread to date.
Careful, VB6 net is going to "get" you. Better crawl under the bed.
Ok, I went back and read post #1. I guess the entire thread was insane from the beginning and I realize I don't care about it after all.
I guess I forgot I was assuming some implied context.
A VB6 dev who says "I can't read C#" is making a fair argument, I don't expect them to have studied the .NET Framework. And I don't pitch C# examples at them, and in general don't hang out in the VB6 forum because I don't feel qualified to answer those questions. Unless someone specifically calls on me to provide some C# example in a VB6 forum. Which would be strange.
A VB .NET dev that says it, on the other hand, is saying that they're not up to the task of parsing lines like this representative of the esoteric, confusing C# syntax:
Code:
var myForm = new Form1();
myForm.Show();
I can't think of a good analogous situation for VB6, there weren't any other languages I know of that use the runtime, and "I don't understand API" is sort of why people liked VB6 in the first place so it's not a good one.
You're right though, post #1 is weird. I skipped to the end to see what was going on and found some people bickering about whether VB6 was OO enough to be a "real" language, or whether VB .NET being OO meant it was too complex. Then we wound our path through a lot of topics. I wonder how the lawsuit's going?
This answer is wrong. You should be using TableAdapter and Dictionaries instead.
Well there's a little bit of the same thing in the (small) B4J community.
That language compiles to JVM bytecode (probably by preprocessing it into Java first), and programs often make use of Java libraries repackaged so the B4J IDE can accept them but... don't bring up Java literacy as useful there or be prepared for backlash.
The suggestion alone brings up all sorts of fears and a rabid defense against it arises immediately.
The only option is to migrate to a Chrome app and Google has provided a guide to how to do it. This seems to be fairly easy. You have to update the manifest and set the Content Security Policy to something reasonable. Beyond that most of your existing code is reusable but you have to take account of a slightly more complex lifetime model and events.
What is really surprising is that after so very long it still seems to be difficult to implement a system for web apps that makes them the equal, or even nearly equal, to a native desktop app.
Summary: Chrome Packaged Apps (CPAs) are dead and gone. Now all you have are "Chrome Apps" (CAs) which are not the same thing at all.
I suspect the problem was at least in part because a CPA had the ability to access local storage and devices. I'm not sure whether the concern was security or an undermining of Google Drive.
It's hard to tell with the browser app frameworks. It's a shame, because they could be really powerful and useful, but every time I've tried to take a look it's made my head spin.
This answer is wrong. You should be using TableAdapter and Dictionaries instead.
Java just needs to die. Quietly. It's not even in the same league as VB6 and that has been trying (unsuccessfully) to go away. Get Java programmers to realize that their thinking 'outside the box' is really just playing in the dirt. Give them a real language and environment and they will (should) realize that they can'y program or design worth a damn. But then, I guess the proper programmers stuck with it, while the programmer wannabes moved to Java in the mistaken belief that it's 'portable' and therefore better than anything else.
And browser App frameworks are also a stupid idea - a nice experiment, but just ... no (but then, that's what Google was(?) all about, and have been very successful with the 1 in 10 apps/projects that are actually useful, or bring something to the table).
"Ok, my response to that is pending a Google search" - Bucky Katt. "There are two types of people in the world: Those who can extrapolate from incomplete data sets." - Unk. "Before you can 'think outside the box' you need to understand where the box is."
Java's going to be around forever, languages don't die when they're that widespread. And again with the "real programming languages" and "real programmers" stuff!
Until C# showed up, Java was the state-of-the-art in OO languages and it still technically implements a more "pure" approach to OO than C#. Java has a bad reputation for the similar reasons VB6 has a bad reputation:
A lot of programmers don't really care to spend time learning how to write clean, maintainable code.
A lot of projects don't have the budget or time to write clean, maintainable code.
An overzealous application of OO techniques makes just as fabulous a mess as letting the above two situations happen within the VB6 IDE.
It's a cool language, but recently burdened by trying to do things differently than C# for competitive rather than technical reasons. The approach to generics looks like madness, and came far too late. As a result, its lambda support also took too long and has questionable merit. The "wannabes" end up in Java because it hits all of the high points of a viral language: it's free, it's powerful, it's C-like, it's cross-platform, there's 4,000,000 articles on how to do any task in it (some of them right), and PHBs feel like they know what it is and that it's "stood the test of time."
But really, cross-platform UI is a big deal. I used a Java-based tool for automating a browser game for a while, and that it was distributed as a .jar meant I could keep it in one Dropbox folder, with all my customization scripts and logs, and it just ran on Windows or Mac and I could play my game whenever I wanted wherever I wanted. I can't do that with C#. I can't do that with VB6. I can't really name a language besides Java that can produce a self-contained executable with a GUI on all platforms. Even having a bad implementation of that is better than having no implementation.
Last edited by Sitten Spynne; Aug 26th, 2015 at 09:40 AM.
This answer is wrong. You should be using TableAdapter and Dictionaries instead.
Unfortunately Java can't die. MS has, so far, done a terrible job of actually delivering on the cross-platform promise of .NET by refusing to spend money on anyone who wants to use .NET without a Windows license. That means, for the entire lifetime of .NET, if you needed to target Linux/Mac/embedded systems you were either at MS's mercy or using Java. It also got a very, very big boost from being the preferred API language for Android.
.Net Core is far from trivial or pointless, but it doesn't offer anything to most current .Net developers because it is a tiny subset of .Net technologies.
The .NET Framework is still the platform of choice for building rich desktop applications and .NET Core doesn’t change that.
For Visual Studio 2015 our goal is to make sure that .NET Core is a pure subset of the .NET Framework. In other words, there wouldn’t be any feature gaps. After Visual Studio 2015 is released our expectation is that .NET Core will version faster than the .NET Framework. This means that there will be points in time where a feature will only be available on the .NET Core based platforms.
We’ll continue to release updates to .NET Framework. Our current thinking is that the release cadence will roughly be the same as today, which is about once a year. In these updates, we’ll bring the innovations that we made in .NET Core to the .NET Framework. We’ll not just blindly port all the feature work, though – it will be based on a cost-benefit analysis. As I pointed out, even additive changes to the .NET Framework can cause issues for existing applications. Our goal is to minimize API and behavioral differences while not breaking compatibility with existing .NET Framework applications.
So not only is it a subset of .Net as you know it, it's a fork of .Net as you know it and expected to diverge from the .Net you know. That's good news, since it means fewer breaking changes as time goes forward.
But .Net Core has a different purpose than the .Net you know. It has no WinForms, no WPF, no lots of things.
Originally Posted by szlamany
Reply With Quote
if the query is solved & Rate those who have helped you 
