Printable View
As tg said - one app. In my case CONFIG differences based on user role and/or sitesettings config's
Even when I did my last VB.Net traditional WinForm (not 4GL) I still had the sales and CSR and manager versions in one app.
One app satisfies my DRY needs...
Which is basically the whole point of separation of 'layers'.Quote:
Originally Posted by FunkyDexter
You effectively have your interfaces 'task based' determined by the user of the system at a given point; don't show the user information that has no relevance to the current task.
My biggest issue with the multi-exe approach: maintenance. Consider my example, where we have a revenue data that is shared between the call center and accountants... if I want to make a change to a screen to show some additional data, I would only need to do it once... but with FD's setup, it would have to be done multiple times... O.o The accountant and the call center person may arrive at the same page differently, but the change still only needs to be done once. And I don't know about anyone else, but there always seems to be that ooooooone person that wears multiple hats, if everything is contained in a single app, then it's easy to give them access to the different areas they need, w/o sacrificing the security of other users who aren't supposed to have access.
-tg
Explicit vs. implicit typing:
I think if you write clean code it doesn't matter. I go back and forth on this but over my career I think I've spent more time swearing over "look, int to char SHOULD be legal, I just can't figure out the right conversion method" vs. "oh, dang, who would've predicted that 'customers' is an array of customers not a Label?"
I think a lot of people don't care to write clean code. I find those people tend to make the same mistakes in a "type safe" environment as they do in a "type promiscuous" environment, though sometimes they're more "successful" when the compiler tries to fix their mistakes.
I want to say, "The trouble is, they never learn that the compiler is helping them." But I don't know if I agree that they should have to. Consider calculating a percent from two integer values in VB .NET vs. Python:
Which of these looks like something you'd write on the first try? Which of these looks like a complete waste of time? This represents 90% of the "type errors" I get in C#, when I forget that I need to be REALLY explicit about whether I mean for division to be floating-point or not. It is almost never that I am trying to assign an Apple to an Orange variable. It's easy to contrive a case where the Python behavior is wrong, but I'll argue based on my experience that coercing division to an integer result is a more natural idea than coercing division to a floating-point result.Code:Dim percent As Integer = CInt(Math.Floor(CDbl(apples) / CDbl(totalApples) * 100))
percent = apples / totalApples * 100
VB6 trips up its fair share of people with implicit typing, but I like that I can turn it on and off in VB .NET. I don't know if I think telling newbies to always use Option Strict is as healthy as teaching them about writing code that doesn't look sensible when you make the errors Option Strict protects you from. But either way, we do have to teach them a lot about Integer vs. Double and how and when to go back and forth and it just seems useless.
Database UI discussion:
It looks like some form of Presentation Model to me, and the benefits you gain by separating UI from all other logic are manyfold!
Who is teaching them, though? Certainly not the forums or the internet, although they may learn a few things.Quote:
Originally Posted by Sitten Spynne
All these proper (sic) coding techniques generally come from a formalized education. This is where Option Strict comes in. Yes, people should write explicit code right out of the gate, but they don't. No one does, because they don't know what they don't know.
Option strict should always be on for newcomers to VB. Once they understand what it is telling them, then they have the option of turning it off when appropriate. It's a poor substitute for proper education, but at least they should be writing less buggy code.
The fact that you have to 'teach' someone using a high level language the difference between an integer and a double demonstrates that they are a novice 'journeyman' and not a programmer. Because people use the internet as a source of education is why we end up with crappy, buggy, useless programs 90% of the time.
I think this is why VB6 programmers tend to linger on. While I wouldn't necessary go so far as saying that VB6 programmers are, by definition, good programmers, but they learned in an environment where there was no internet or readily available knowledge. They had to rely on books and publications (and not your 'everybody make a book which repeats the help' type books, or 'stupidity for dummies'). They had to actively learn. It's tough to throw that knowledge away, especially to move to a language where the average programmer is [perceived as] a stumbling retard who can't find their way out of room with the door open.
One slightly worrying thing I'm getting (possibly incorrectly) from your replies is that it sounds like your screens are closely tied to your functions. I.e. there one screen and only one screen for entering orders. I would view that as a bad thing because I often want to present several different views on the same function. An order might be entered by a customer, a salesmen in the customer's house, a telesales operator, a back end admin and so on. These guys all want the same business rules applied but what they need from a GUI is very different. A customer wants nicely presented pictures and customer reviews. A salesman might similarly want pictures (to show the customer) as well as a discount calculation. A back end admin probably wants a simple grid with as view keystrokes as possible and no whizzy bits. I'm sure you're already ahead of me on this but do a brother a favour confirm that you haven't ended up creating a single view per function. I'd hate that.Quote:
I read a little more about your example - we would develop that in one app - each of those segments would be an "Area" which then consists of modules for specific functionality.
The other thing that's slightly worrying about your approach (but I don't think is a hard limitation, it could be worked around quite easily) is that it seems limited to providing a web UI. Could you consume this through a desktop or Mobile app? I imagine you could as the sprocs/services/whatever you use to expose the model could be consumed by a different UI. Is that right?
At first glance it sounds like your GUI is strongly coupled to your model and data but the more I look I'm not sure it is. You happen to have stored your GUI in the database but there's nothing intrinsic about that decision that couples them. Could you, for example, keep you GUI definitions in one DB and your business logic and data in another?
One other thing. In my experience sprocs tend to be inherently bad for unit testing. They don't decompose into nice small units and it's very difficult to mock their dependencies. Are you guys doing any form of unit testing (ideally TDD) and, if you are, how were you able to overcome these issues? (It's this, above all else, that makes me leery of sproc based systems so I'd love to hear how others have approached it).
Overall I think this sounds like a good approach. I can see some slight worries and niggles but none seem insurmountable and I can definitely see how it enables quick, RADish turn arounds.
We don't do sales per se... our product is used by the non-profit market - the enterprise types, massive donation raisers, American Heart Foundation, American Diabetes Assoc, Canadian Diabetes Assoc, World Wildlife Foundation, Salvation Army, just to nae a few few - so it's hard to make a fair comparison, but I'll try - the answer is yes and no. there are some cases where we use the same form in different areas - like entering donations - but there are times when we do have a different side of the die showing depending on where you come from. there are two ways of handling that - one is by affecting its bahavior through the context ID (a GUID that provides a "You are here" context. The other is by having a different screen and then determining if it's hidden/shown based on security. so the call center may get the full payment entry screen while someone else gets a slimmed down version even though both accessed it from the same page. Behind the scenes, we'd have two "Add payment" actions, but one is hidden due to security. It makes for fun times when a bug is reported and the developer is in the wrong role and gets the wrong screen. So no, it doesn't have to be one view per function, it can be, but doesn't have to be - case in point, that payment screen I mentioned... I happen to know that there are no less than FIVE of them depending on where you are - I've had to customize them all.Quote:
Originally Posted by FunkyDexter
We sued to be desktop - click once deployment. In 2007 they introduced the web client and went hybrid. In 2012 the desktop/click-once and adopted the web client as the official interface. but we do expose our entire web service - same set of services we use - to any client that wants to know about it and they can even then build their own apps on top of that api and interact with the system.Quote:
Originally Posted by FunkyDexter
No, the UI is not strongly coupled to the data model... anything but... I suppose it could be and in the SDK training it does come off that way, but when you get into the nuts and bolts of it, it really isn't. Could it be separated out into a different database... maybe... but the underlying architecture of the platform would probably need some serious rewiring to essentially read from different databases. What we can do though is easily separate the application (IIS) server from the database server. In fact I have one client that not only is doing that, but their application servers are part of a farm, as is the database server.Quote:
Originally Posted by FunkyDexter
At our level, we don't use unit testing or any testing process (other than yep it works and send it off to QA for testing) it's more functional testing. The products team does use a more formalized testing process... I'm not sure what they use exactly, I but I do know they have something. Sprocs themselves wouldnt' get tested, but the exposed service point would... whether that taps a stored proc is irrelevant - even in TDD the end point is what would be wired up to the harness... eventually that end point might talk to a stored proc, and if that sproc fails, the end point fails the test as well... so if it passed the test before, then failed after adding the sproc, then you know the failure is in the sproc. At least that's how I've dealt with it in the past. Another is to treat the sproc as the end point and the calling end point as the testing harness... so the sproc does nothing initially and returns a clean run... then as you build hte sproc, you continually run the tests, and if it fails, then you know the last thing added/changed is the failure point.Quote:
Originally Posted by FunkyDexter
What I like about it is the speed at which we can deploy something... push out the assemblies, load the specs into the database, and it's there. Occasionally we run into issues with browsers caching things, but it usually happens in the development cycle when the change rate is high.Quote:
Originally Posted by FunkyDexter
It can be a lot of fun to work in, and infuriating at the same time. There are few things I'd like to see done differently. But over all, it's quite the system.
This is a myth. I spent 8 semesters getting my Bachelor's in "Computer Science and Engineering" and even though I took a 3-hour "Software Engineering" course, it was really a slightly more software-focused "Project Management" course. We talked about estimation, we talked about waterfall, we talked about testing, but we did not implement a single line of code in that class. Every bit of "proper" practices I know has come from either reading a book, reading blogs/social media, or writing terrible code then begging people to help me improve it. I don't know anyone else that learned much about coding style in college either. Unless things have changed dramatically, it's still something you are expected to either self-train or get on the job.Quote:
All these proper (sic) coding techniques generally come from a formalized education.
I really don't like the rest of your post, either. I feel like you use "VB6 developer" as a derogatory term. You mean "Mort". Mort is distinctly Microsoft, because Microsoft's sales pitch is "Programming is easy, you don't need any kind of training to be a programmer." That is false, and damaging to Mort.
For a whole class of relatively trivial application, Mort's the best fit. No one wants to pay my wage for a single-screen CRUD app. My degree of architecture is overkill for it. But invariably, because it's non-technical bosses that need Mort most, eventually the needs of the application outgrow the "no-architecture zone". That the whole of Windows training materials treats architecture as "for nerds" means Mort is completely unprepared to recognize this.
Mort doesn't have a problem and ask questions like, "What patterns exist for sharing data between multiple forms?" and spend a few days prototyping approaches. Mort asks, "How do I make Form1.Button2_Click() get data from Form3.TextBox4?" and uses the first answer that can be pasted into his solution. This works in perpetuity because Mort works alone, doesn't have code reviews, and often his boss can only use "does the software work" as a measure of success.
This excerpt from a beginning Python text lays out disciplined rules for writing If..Then statements. In Windows books, this advice isn't present in any of the 15+ texts I read. It's stashed away in "Code Complete", the "just for architects" book I ignored for 4 years. It could've saved me dozens of hours over those years, but the Windows productivity myth had me believe that kind of thinking was for PMs, not developers.
The problem isn't VB6. The problem is that Windows has to sell itself, and to do so it has to put VB6 in skimpy outfits and ask it to do questionable things. You don't see as prevalent a Mort community in other languages because they don't pretend programming is easy, they integrate basic architectural thinking into their tutorials. We, as a community entity, can't reverse this so long as the "official" materials distributed by MS and their evangelists perpetuate the "You don't need to think to program" myth.
Most people don't read architecture books or specialized architecture blogs. They only learn proper practices if tutorial materials and community examples advocate those practices. When even the language designer favors quick fixes and results-oriented thinking, there's almost no hope. I didn't get any of my respect for architecture until I branched out into other, non-.NET languages.
So I really, really, really think the next VB6 won't be a VB and won't come from MS. It's probably already present, being used productively by tons of new developers. But we don't recognize it, because what we tend to mean by "new VB6" is "a happy toolkit for making turnkey applications with wizards", and that isn't exciting to anyone for very long.
I see this as far more of a .Net issue than a VB6 issue. The bar to entry is far lower via the Express and now Community Editions for one thing (free vs. paid-for tools), and more people attempt this now than in the heyday of VB6.
I'm amazed we see as much VB6 "traffic" in help forums as we do for those reasons. I can only chalk that up to people who got comfortable in Office VBA and persisted until they somehow got their hands on VB6, and more and more often probably the pirated "Portable Edition" floating around warez sites.
But the proof of my premise is in the forums: VB.Net and C# forums seems to contain just as much Mortitude as anywhere else. You only see a higher proportion in web scripting forums.
That's been my most commonly used technique although sometimes I only partially apply it:DQuote:
writing terrible code then begging people to help me improve it
I agree with a lot of the rest of what you've said but I don't think I'd limit it to a criticism of VB6. I see them same in VB.Net and I've definitely seen it in the web development community as well. I used to work with a bunch of data scientists who used Python to query their models and I saw it there too. Come to think of it I think I've seen it to a greater or lesser extent in every language I've worked in. It shouldn't be surprising as "make it work" is the job these people are paid to do. "Design me an architecture" is not. I don't condemn that sort of thinking - it's pragmatic. It doesn't particularly turn me on but I don't condemn it. In fact, it has served me well on many of the projects I've worked on.
In fact, I think this may be one of the cruxes of the 6 vs .Net debate. 6 was only ever intended to serve that kind of quick and dirty approach and it does so with aplomb. The fact that someone with enough skill can take it further is great but it tends to require them to use hacks and techniques the designers never intended or to compromise on the design. .Net was intended to support a more engineered approach from the start. How well MS succeeded in delivering on that intention is subjective and I'm sure we can debate it until the cows come home but the existence of the intention should be undeniable.
I can't remember the members name but we had someone who weighed into these debates and their entire argument distilled to ".Net users are to stupid to use 6, you've got to be a genius to use it". That always struck me as a really stupid argument because the whole point of a language is to make your life easier, not harder.
edit> looks like Dil and I crossed over and said... almost exactly the same things. Guess it's time to book that snowboarding trip to Hades.:wave:
What I find always happens in a discussion of Morts is we act like there's only one kind of programmer, and one kind of job. The reality is there's a whole range of programmers, much like a range of plumbers. Some plumbers are licensed, bonded, only take on big contracting jobs, and have a reputation for doing lifetime work. Others are licensed, bonded, and do the best they can to fit your budget with quality work. Some are licensed, bonded scam artists that will cut any corner they can while staying "legal". Some are just your buddy with a set of tools.
Now, there's a problem. You hire a plumber because you are not a plumber. So especially when you are considering a big job, you may not understand why one plumber's estimate is so much more expensive than another's. There's lots of materials and practices involved, maybe the more expensive plumber works to provide "lifetime" work while the cheaper one works for "good enough". When you don't know what either of these mean, all you know is one looks silly expensive for what you feel is a small job.
This is exactly like programmers and projects! In every language, you have people of every skill level from "proven guru" to "wrote some hello worlds". They often demand wages and compensation in line with their skills, though the people in the middle are fraught with peril and risk. But our projects also vary wildly in complexity.
Mort's a great fit for projects that don't have a lot of complexity. Mort is cheap and gets the job done. When you've got a leaky sink, you find a friend with a pipe wrench and offer a beer. It turns out there's a lot of people that meet the criteria "has a wrench and wants a beer".
Mort can struggle his way through projects with medium complexity. It's hard to say what "medium" complexity is without being a developer yourself. But multiple screens and functions in one application tends to do the trick. Here, a more experienced developer can be dubious vs. Mort: an experienced Mort might be neck and neck. I think this is the segment of programming where most bad decisions are made, because it's almost impossible to tell if you're choosing the right person for the job.
Mort's hopelessly lost on very complex projects, like a high-reliability banking system. They require specialized knowledge and a knack for managing complexity that only comes with experience. There's maybe a few dozen people in any market that can write this at all.
So when we talk about "VB6 being a toy language" or "VB .NET dumbing things down", we're often looking at a scenario where someone asked Mort to do a job he was unqualified for. That's not the wrench's fault, that's the project manager's fault. But sometimes, the project manager's just some random business owner that knows she needs a programmer, but doesn't understand anything at all about it. She doesn't know how to find a good programmer, and has to go through random ads or shady recruiters. What she ends up with is a poor fit for a poorly defined project that any seasoned developer would recognize. She thinks she has a leaky sink and hires a cheap, unlicensed plumber, but in reality has corroded pipes that need to be replaced. The plumber doesn't recognize the real problem, and months later her pipes burst, causing tons of damage.
And what do we do? We chuckle and say, "That's what you get for hiring a plumber that doesn't use this brand of pipe wrench."
I'm imagining a Mort plumber, desperately trying to fix pipes that are spraying water everywhere and have been for four hours. Water's pooled in the room, and everything's waterlogged. The plumber's screaming "IT'S FINE! THIS IS UNDER CONTROL!" The homeowner looks on, nodding their head. "Wow, this is messier than I thought. I'm glad I hired a plumber."
Programming is the only reality where this happens! And we laugh and sneer at the people involved. That makes me hurt a little.
There is much wisdom in these words.Quote:
So when we talk about "VB6 being a toy language" or "VB .NET dumbing things down", we're often looking at a scenario where someone asked Mort to do a job he was unqualified for.
Of course it is, you are right. However the VB/VB.NET eliminates the arguments between languages with complete dissimilar roles.Quote:
Originally Posted by dilettante
And yes, the barrier to entry is very low. That's why we have crap software because anyone with an internet connection can see themselves as a programmer. I'll say it again, without a formal education, one is going to be seriously laking in skill and capability. Yeah, some people don't like it, but then people are more 'sensitive' to the truth when it doesn't fit their world view. The world smacks them down, and they complain there are no jobs for skilled workers, not realizing they don't have skills worth paying for.
If there were formal training that made a good developer, we'd have a licensing process much like plumbers and electricians have. I'm very, very confused what formal training you think exists that produces good developers, SJWhiteley. I've never heard of such a thing, nor have any of my coworkers or our recruiters.
My 4-year degree taught me the plumbing equivalent of "being able to use a faucet and identify its parts". Learning to disassemble it, diagnose problems, and fashion faucets out of thin air came from reading books no one told me to read.
If you pointed this out to them, would they be Mortified?Quote:
Originally Posted by dilettante
From what I have seen of research into the field of development there is no solid way to ensure that you are finding good programmers other than finding programmers who have done good work. No badge, diploma, or certification appears to have any particular merit.
The above sentence needs a correction (again):Quote:
Originally Posted by FunkyDexter
VB6 was never intended to serve *only* the quick and dirty approach - but it does so with aplomb.
VB6 has everything what's needed, to write well engineered Apps in a clean way - to workQuote:
Originally Posted by FunkyDexter
like that requires just about the same "skill level" which is common also in other languages,
and that has nothing to do with "taking it further than it was desigend for" - e.g. COMponent-
services which allowed transactions were introduced into .NET very late - and were then
based on the very same COM-backbone which served VB6 for years already.
No Hacks I'm aware about are needed, to write well-engineered and complex Apps in VB6.
Wondering when it will sink in, that it is never about the tool - it's just Developers -
their experience and skill-level which decides about software-quality.
And I can only repeat that the only way to do a decent comparison among software-tools which play
in the same ballpark, is to compare Notes after producing a *concrete-solution-for-the-same thing* -
that's after all what software-tools were built for, - anything else is just "speculating around".
Olaf
That would be a really interesting test to be able to run. The problem would have to be non-trivial, and the skill levels of the developers would have to be roughly equivalent in the different languages, which makes the test likely to be impossible, but it sure would be interesting to a lot of people.Quote:
Originally Posted by Schmidt
Ack, that's the spirit.Quote:
Originally Posted by Shaggy Hiker
And another thing I'd like to mention as "food for thought" ...
I guess 90% of our work (especially in LOB-Apps) is quite uninteresting
and for the most part "just boring" (always the same simple DataEntry-
Processing- and Persistence cycles which are "as time goes by" just re-worded
and re-taught in ever new paradigms - the discussion in the recent postings
deriled into "DB-based GUIs" - a thing which an old and experienced Access,
FoxPro, Clipper, VO (put your 4GL-lang here ... 'PowerBuilder' anyone?) - guy has
already done (just not using as many fancy words to describe it) for decades.
That said, what I found though is, that a lot of these large and boring Apps were written
by developers with, say - "average skills". I don't mean that condescending at all -
I would even go that far, that I suspect that these Apps were *requiring* a special
mindset, to "rifle through those boring problems with insistence" - a thing which is
missing in many of the "artist-developers" (who lose interest and "their bite" as soon
as "the challenging things in a problem were recognized and solved").
There's "sprinters" and "long-runners" - the latter type often being the better
entrepeneurs (Mort or not, well-designed App or not - these are the guys who
will "produce" - and enhance+maintain with endurance and tenacity).
Olaf
I've already put some thoughts (as well as quite some work) into that in my post #730:Quote:
Originally Posted by Shaggy Hiker
http://www.vbforums.com/showthread.p...=1#post4917477
This is, as I think a nice mix of DB-related (search)stuff, networking-stuff, threading-stuff -
text-parsing is involved - and a little GUI-challenge is in there as well, all of them things
we use in our daily work as (mainly) LOB-developers.
It's still doable in a managable (teams allowed) amount of time I think - and a few additional
challenges could be added as well (with regards to engineering, which almost always touches
the realm of easy extensibility...
E.g. one could require in addition, that the App should be already designed in a way, to allow
easy movement of the Server-part to a WebServer - and the GUI-Part into a Browser (as a
kind of "customer-change-request").
Would like to see solutions in other languages as well (e.g. a Javascript, or Python-solution) -
not only .NET or VB6 as the contenders - a Forum for that is already there - and when it's
indeed well-engineered solutions which come out in the end - we could make that even a
sticky-thread in the contest-forum, kept alive to allow other interested devs to provide
better designed or optimized solutions over time - and stick them in there.
Olaf
To my clients my skills are being able to sit through long meetings about why we won't cover transplant surgeries or how we want to change the pension plan year to calendar (from Oct-Sep) and "what exactly do you do with those 3 months" and turn those meetings into deliverables that are an exact match.
The fact that I am bored is why I created my own 4GL for delivery of those solutions.
And all the while I use those funds to finance a startup doing natural language processing - wrote my own REGEX - all in C++. I've got a patent on a database concept to go with all this. The boring front end to all that is a document management system.
I would love to offer a JavaScript attempt - although it would have to fake a DB since it's all browser.Quote:
Originally Posted by Schmidt
That would be great - and when you read the requirements really carefully - the Base-Data isQuote:
Originally Posted by szlamany
a simple ASCII-TextFile (which requires parsing into "more efficient InMemory-structures",
which will then in turn allow for a better FullText-Search, to be able to serve requests faster
to the client-side).
So, no real "persisting DB" allowed in this scenario... on the server-end exists "read-only-
access to the FileSystem" (think: "CD-ROM which contains only the Bible-Textfile")...
And for those who already start with a http-based Browser/Webserver-solution (any WebServer
allowed... Node.js, Apache, IIS, Mongoose - homegrown ones) - the (additional) design-
requirement could be, that one will earn "extra-points" for ease of movement (amount of
reusable code) to a perhaps better performing "non-http-based" solution (serving a normal GUI
over WCF for example) - and vice versa for the guys who start the other way around ...
Olaf
"Mort" is less a description of programming skill than a description of what a programmer does and how he goes about it. More of a role than a skill level.Quote:
Originally Posted by Shaggy Hiker
Mort may be writing code as an adjunct of his "real job," whanging out quick solutions in the absence of greater resources that could be applied to more engineered or crafted solutions. He might be a front line coder primarily doing maintenance work on existing software. It's a case of simple economics: some roles require low costs and quick results more than they do great expertise and care.
You don't need a horticulturalist with 10 years of practical experience to mow a lawn, so it isn't worth paying one to do it. He may get bored and do a crappy job too. That's why you see those carnies driving trucks around hauling mowers on trailers. For all we know some of them have advanced degrees and a ton of experience but got laid off and are just doing what work they can find, or maybe they've decided to slow down and get off the treadmill.
I think "Mort" describes what you do and not necessarily what you are capable of.
Yeah, I really like that description, dilettante. That's why Mort doesn't "go away", and why sneering or blaming this or that language for Mort's existence isn't very productive.
If someone rubbed a magic lamp and used their wish to gain the ability to educate every developer to Knuth's level and beyond, everyone would write great, clean code. But the need for boring CRUD apps (and not all CRUD apps are boring) wouldn't go away. Now someone fit for writing the code for self-driving cars has to "stoop" to writing those CRUD apps. That's not really an effective use of resources.
So really, we should be sort of glad people are out there to fill Mort's role. They fill jobs a lot of us would be bored to tears taking. Unfortunately, it's not widely known when a manager should take a Mort off the job and put in someone that can clean up the mess. That's when non-Morts feel pain and curse Mort's existence.
I like for people doing Mort jobs to aspire to more, but not everyone can cut it. If we want to "fix" things, maybe our efforts are better spent educating the people that hire Morts about choosing the right developer for the job. Either way, VB6 and VB didn't create Morts. They just made it easier to find a person that was willing to do Mort's job.
Sorry I missed that post. I headed into the woods on that day and just got back. Considering the impressive amount of writing from then until now, I decided not to read all the posts that I missed.Quote:
Originally Posted by Schmidt
The suggestion is a really good one for a coding contest. It isn't terribly difficult, nor is it trivial, and it does manage to avoid being about math tricks. Unfortunately, I also think it's liable to be DOA just like (most of) the other coding contest suggestions. I'd like to see it come about...but I barely have enough time to waste posting on VBF already, and I would expect that others feel the same way.
However, the more I think about it, the more I think that your idea has merit beyond just voluntary work on a forum coding contest. It isn't my field to be studying coding efficiency, but I wouldn't be surprised to find that some company like MS, Google, or some such, might be interested in funding a true study of coding efficiency in various languages, and that problem seems like one that could be done. The one change I would suggest would be that the document being searched might be something that was large and a total snoozer, such as the Congressional Record, rather than a more controversial text like the bible. After all, with the Congressional Record: Nobody would already know what was in there and nobody would know what was NOT in there.
Well, thought so too...Quote:
Originally Posted by Shaggy Hiker
It's targetting more the "LOB- and Enterprise-Development for the Win-Platform", which I think
most of the VB* and C# professionals have quite some experience with...
As for "Dead-On-Arrival" (in the contest-forum) - since I was making the suggestion,
you can count on that I'll provide a VB6-based solution.
A Javascript-based approach seems already to be considered by szlamany (I'd suggest Node.js to implement the
serverpart in his case, and for the 8 stresstest-threads in the BrowserClient there'd be WebWorkers since HTML5).
So the only thing missing is the commitment of one (or a few) .NET-developers who'd like to invest
"a day or two" as well, to make that already a worthwhile "thing to study and refer to", when finished
(not only for the sake of comparison between languages or development-platforms, but within a given
language/platform also for folks who will profit from a well-implemented "wireframe" for this kind of problem).
Just looked at the thing - but it's quite a complex animal "structure-wise" - not that easy toQuote:
Originally Posted by Shaggy Hiker
rummage around in (and to define *what* to parse or index for Full-Text-Search and -retrieval).
The explanation for the "Bible-parsing" I was able to do basically in a single sentence.
(I gave a Link to a Zip-File along with the structure-def: Books/Chapters/Verses -
any given Verse then being considered a "Document-Node" - to search, and deliver
when a match was found (in one or more Verse-Snippets).
Here is the start of the Raw-Data in the ~5MB Bible12.txt-file:
...and so on... Each "Verse-Document-Node-Paragraph" already beginning with a Prefix-ID,Code:Book 01 Genesis
01:001:001 In the beginning God created the heaven and the earth.
01:001:002 And the earth was without form, and void; and darkness was
upon the face of the deep. And the Spirit of ...
which describes BookNr:ChapterNr:VerseNr - and any new Book in the Text-Document will start
with the same HeaderLine-Format as seen above with "Book 01 [couple of SpaceChars] Genesis".
So the parsing-part is not really difficult to do or understand - just a bit above "beginner-level".
What remains for the server-part is only, to "catalogue" the words (related to the Verse-IDs)
in a FullText-Index (but there's Libs for this part) - and to provide concurrent access over
sockets for the Client-part.
So, for the sake of an easier to understand "task-description", I'd stick with the Bible-Text...
Also cannot see, what'd be "controversial" about it (when used only as a "bundle of words" in quite
the right size and structure, still managable in potential "solution-zips" when they are posted).
As many other nerds I'm a non-believer, but however - it's a nice task - so why not imagine
that "a customer asked for it", threatening you even with a well-paid contract... ;)
Olaf
Yeah, I see your point there. The Congressional Record is a mess.
I got thinking a bit more about the contest as a comparative study. It would be a sociology study, which makes me queasy, but it would require two different studies. After all, the coding contest isn't any kind of comparison between languages. It COULD be a comparison between languages, but only if the sample size is so large that you can tease language differences out from the confounding factors. With just a few submissions from different people you'd really be looking at a comparison of their effort, ingenuity, and language comprehension (programming language, of course). A trivial implementation would be essentially a RegEx of the file. The performance would be horrible regardless of the language, but the code would be very simple. Such a submission would show little about the language. A slightly more complicated version would be chunking the file and using multiple RegEx on different threads/tasks, which would show a bit about languages (JS doesn't directly multithread, nor does VB6 easily), but would still be a pretty poor solution. More complex indexing and heuristical seaches would be more complex and would show more about the dedication to the problem of the developer(s) than the languages.
So, the first study would just be to come up with various approaches, which is what the coding contest does. From that pool, a second study would be to choose one of the approaches and implement that in each language. That would compare languages more than algorithms, though there would have to be some flexibility in the rules because you wouldn't be able to say, "store this in a Dictionary." Instead, it would have to be more like, "store this as key value pairs by whatever means you choose."
I wouldn't theorize that much about it.Quote:
Originally Posted by Shaggy Hiker
It's a relative simple task, which might come in as a well-formulated, clear description in
exactly the way I layed it out in my post #730 also from a customer, who'd be even
willing to pay for such a solution. (which in the end could be a bit larger even, but
the customer wants to decide which way to go, from concrete demo-implementations
which come in from "all the bidders").
We program and develop, to provide such solutions - and we use certain tools to develop them -
and most of us have specialized in using a concrete tool, which has proven worthwhile
to provide such solutions for "typical tasks in a given field" (here, a typical "multiuser-
office scenario").
What I simply want to see is, how well certain tools really do "in the field",
when confronted with such a concrete task (a customer-request, which could lead
to a well-paid contract).
There's nothing "social" about it - just developers and their tools, applied to (always
the same) problem.
Sure, the solutions (when they come in) will reflect different skill-levels - but when a
certain solution outperforms all others by quite some degree in "measurable regards" as e.g..:
- deployability (ease of installation on different systems)
- lines of code used
- general design (extensibility and structuring of above code)
- performance (here measurable over the achieved requests per second)
- GUI-design (usability and general appearance)
Then questions could be raised, why all the other provided solutions were doing that
badly in comparison.
If it is due to the skill-level, then - by all means - a more skilled developer (who's using the
same tool) should be able to step up and point out the mistakes which were made in applying
certain stuff to the one(s) who posted this not really competitive solution (or he could
send in a better one himself, to underline what the tool he's using is really capable of).
So in the end - when we keep this contest "open" over a longer time, we should see
the effects of this kind of self-correcting "leveling-out" of the different solutions.
I fail to see why something like that shouldn't be worthwhile.
Let's assume for the moment, that VB6-solutions are indeed "better" in providing concrete
and practical solutions than their .NET-based equivalents (which, in the end, they aren't -
they will just look a bit different...).
But then, when the next .NET-guy comes along in a thread like this stating that:
"my tool of choice is more capable than yours, it's time to move on" - one could simply
point him to the accumulated solutions - and ask him to give proof for that statement
(since the results were telling otherwise, so far...).
He could then choose one of the already existing .NET-solutions (to save time) - and simply
show everybody, "how it's done better". If he fails to do so, then he was either wrong in
making his statement - or he didn't have the skills (yet) to come up with a better solution.
If it's the developers skills which were lacking - why should other developers listen to specuations
of somebody who has still some climbing to do on his own personal learning-curve?
That's my simple line of argumentation - dont' speculate, don't theorize - just formulate
a concrete "customer-task" and show the code which "solves this exact problem".
Other users of the same tool who think that you solved it inefficiently, will step in soon enough.
As for Javascript-Threading... this is not that difficult to do - WebWorkers are an established
entity for a few years already - the coding-efforts are comparable to other languages -
this mandelbrot-worker here (original folder: http://people.canonical.com/~jamesh/fractal/)
has rougly the same volume as the code in a VB6-ThreadClass, also calculating a "single Row of Pixels":Code:self.onmessage = function (event) {
var data = event.data;
var c_i = data.i;
var max_iter = data.max_iter;
var escape = data.escape * data.escape;
data.values = [];
for (var i = 0; i < data.width; i++) {
var c_r = data.r_min + (data.r_max - data.r_min) * i / data.width;
var z_r = 0, z_i = 0;
for (iter = 0; z_r*z_r + z_i*z_i < escape && iter < max_iter; iter++) {
// z -> z^2 + c
var tmp = z_r*z_r - z_i*z_i + c_r;
z_i = 2 * z_r * z_i + c_i;
z_r = tmp;
}
if (iter == max_iter) {
iter = -1;
}
data.values.push(iter);
}
self.postMessage(data);
}
So, also with Javascript one could fulfill all the requirements of the task I layed outCode:Public Function CalcRow(ByVal RowIdx As Long, ByVal RowWidth As Long, _
ByVal MX As Double, ByVal MY As Double, _
ByVal xStep As Double, ByVal yStep As Double)
Dim x As Double, cx As Double, cy As Double
cy = (RowIdx) * yStep + MY
For x = 0 To RowWidth - 1
cx = x * xStep + MX
pRow(x) = LUT(MBColorIdx(cx, cy) Mod ColorCount)
Next x
CalcRow = Array(VarPtr(pRow(0)), RowIdx)
End Function
Private Function MBColorIdx(cx#, cy#) As Long
Dim it As Long, x2 As Double, y2 As Double, xx As Double, yy As Double
xx = cx: yy = cy
Do
x2 = xx * xx
y2 = yy * yy
If (x2 + y2) >= 4 Then MBColorIdx = it: Exit Function
yy = 2 * xx * yy + cy
xx = x2 - y2 + cx
it = it + 1
Loop While it < MaxIterations
End Function
without jumping through hoops.
Olaf
I certainly think it is worthwhile, but I doubt that a coding contest for a problem like that would show anything at all about the tools used. After all, if submission A used a straight RegEx solution, but submission B made use of some clever caching and indexing, B will be larger, but could be MUCH faster. Considering that we tend to find solutions by inspiration (prior to some point we only believe that an answer exists, after that point we have a good solution in mind....we've probably all experienced that state change in our minds), a great deal of the difference in solutions may have nothing to do with skill or tools, but inspiration...which may be due to experience, so it may be a measure of skill, but that isn't clear.
We are both considering a means to test variations between tools, which would be the ideal outcome, but the differences between people would be pretty stark in the initial round. However, if person A provides a solution in VB6 and it is faster than that provided by person B in VB.NET, then the two algorithms could be compared. If the algorithm used by A is superior to that used by B, then B could take the algorithm from solution A and re-write in .NET. At that point, you are comparing the implementation between the two languages of the same algorithm.
So, I would say that the first round would be to try out different algorithms, while the second round...if it even happened....would be able to compare the languages more directly. I'm frankly pessimistic about people putting that much into it, though. As you noted, there is some interest, so it could happen, but I'm still pessimistic.
EDIT: I am working on devices that don't have lots of HTML5 stuff implemented. I havn't tested Web Workers on those systems yet, but then again, I barely do any JS.
Don't Get Me Started - VB6: Waking a Sleeping Giant
https://msdn.microsoft.com/en-us/magazine/mt632280.aspx
We already have 98% of what his "VB*" would do already, and arguably maybe 1000% of what it would do since we don't have to give up ActiveX: HTML Applications (HTAs).
No it doesn't use HTML5 and no it doesn't compile down to JavaScript. But otherwise it is a giant superset of what a "VB*" as described would do.
The downsides are lack of portability (because VBScript is very ActiveX-friendly) and lack of performance (because the bathless .Net horde at Microsoft actively opposed any optimization and enhancement to VBScript).
So if you demand portablity and better performance HTAs don't cut the mustard. Otherwise they do and all you really might want is a decent IDE (something we never got).
If those aren't important to you then I'm not sure what a "VB*" brings to the table that you can't already get using some other language. And if they are important to you there are lots of other languages.
It's almost as if he thinks VB6 is about the language syntax and nothing else. Surely he can't be that dense?
And even if such a thing did come along, it would not have that stability of VB6. That is an entirely accidental side effect of its deprecated status. Stability was what he based his whole notion on:
So I'm not sure the article adds up to any kind of sense at all.Quote:
I was having lunch with a client some weeks ago. He has a Silverlight-based solution that displays video from security cameras. But Microsoft has now deprecated Silverlight, encouraging developers to switch to HTML5 instead. “That’s a pain in the ass,” complained my client. “I was doing fine with what I had. Now I have to go learn another language and migrate all my code. My app isn’t all that complicated, just a few video streams and some buttons. I wish there was some way to make that really easy.”
Thank you Skreener!!!! I must say after trying to migrate my code from VB6 to VB.NET is just absurd. VB.Net is three times the work that VB6 is, just to do the SAME THING.Quote:
Originally Posted by Skreener
Results may vary. The migrations I've done had no appreciable difference one way or the other.Quote:
Originally Posted by DFPCNC
Here's the other side of that migration coin.
One of my first big .NET projects was a multi-threaded file searcher that looked for suspicious files like .mp3s on a vast collection of network shares. If you asked me to write it again today from scratch, given a firm set of requirements I'm pretty sure I could hit every high note in a week and have something robust/showable in 2. If you instead handed me the source code and told me to migrate it, I'd have to budget at least a month, with no guarantee I'd have all features present.
It'd take a week just to comb the code and figure out what features were implemented, and if there are any that were attempted but aren't working. It'd take several days to decide how much of it I could reuse. Development would move slowly, because for every new feature I'd have to test it first in the old program, then compare the new program to it and prove I did the same things the same way.
Porting a program is hard, especially when you have less experience in the new language. That's not .NET's fault. It's like you studied French for a year, then were handed an entire novel to translate. Of course your native language will seem so much easier. Ask a French native to do the same, and their complaint will be that your native language is what makes it so complex.
But considering we get better as developers as time goes on, even that metaphor isn't complete. Porting a program is more like being handed Moby Dick in French as written by a second-grade student with D marks, then being asked to write it in English. If you think English or French is the source of difficulty there, you have some bad thoughts to deal with. There's certainly some clunky mechanisms in .NET, but it's fascinating how quickly we forget that over decades with a language, we learn how to work around its rough edges.
I agree that "porting" woes have less to do with the old and new language than other factors.
Working from requirements can be a lot smoother. However with legacy code of any serious vintage any requirements documents remaining are probably far out of date. Even good requirements documents don't get updated with every nuance of the adjustments made in requirements between the start and end of the original development effort.
Porting old applications is just hard.
In one shop I used to work at they had a vendor come in to "help run" a project to convert some mainframe systems to Windows. For "fire one" they chose VB.Net and sent a lot of staff to formal training in it.
Most of the programming was done by the vendor. The idea was that the shop's permanent staff was going to take on long term maintenance after delivery. Well the project failed miserably after lots of time and money had gone down the drain. They got less than 1/4 of the new software to a testable condition and performance was a joke.
So next the vendor said "well gosh we need to use C# for better performance, yeah, that's the ticket."
So another round of training. In another language. Another group of vendor contractors. "Fire two," more time, more money.
That was about 5 years ago now. The mainframe software is still in use.
Porting old applications is just hard.
Edit:
I forgot that there was a "Fire Zero" in there. The first attempt was a vendor package "already done, just needs customization." ASP.Net front end. That lasted two years and the interim result performed so poorly, omitted so many requirements, had so many bugs, and had so many browser-based usability woes that it got ashcanned without ceremony.
The ports I've done was a port of a VB6 application to .NET. I had written both, so I was thoroughly familiar with what needed to be done. However, I also wanted to add a bunch of features, which increased the size of the .NET program to about 50% beyond that of the VB6 version, and maybe more. Because of my familiarity with the program, this went about as Sittens first example went: Fast and smooth.
The second program was re-creating a VB6 application in .NET where the source code didn't exist any longer and I hadn't been involved with it. That took a bit longer. I had to study the existing program to see what it was doing for each control, and how it was impacting the database. There were a few fields in the DB that didn't seem to serve any purpose that I could think of and which never changed. If those fields weren't vestigial, the resulting program didn't match what the old program did, but it's hard to say.
Porting depends on lots of things. For one thing, as Sitten also pointed out, when you port a program you tend to start with the assumption that the program you are porting is good (or else why bother?). A few bugs isn't too bad, but if there are features that exist for no known reason, that makes life difficult. Anybody who tried to port the first program I wrote at this employer, which was also written in VB6, and for which the source code was stolen over a decade back, would find features that made no sense at all, including a button that put up random puns, phrases, and limericks. There was a reason for it all back when it was written. That was just two decades back on a vastly different network topology.
Many of the vb5-6 programs I wrote for my current company have died quietly over the years. The major programs in use daily I ported over to VB.NET. Some of them took several re-writes to get right. All of those added new features where I saw improvements were possible. In short they bear very little resemblance to the original programs let alone the code driving them.
Yes porting is mostly a pain for me. Which is why I am very selective about what I do port.
Also I'm kind of thinking the major difficulty with deciding on what a new VB6 would be like is something like this:
From a syntax perspective, we've got many vibrant candidates for language features that'd be great in a non-programmer language. The pendulum could swing to the less-object-oriented VB6 and I'd be fine with it. Buy me a drink and I'd agree it might be easier to teach a newbie how to work with OOP if you first don't let them use OOP at all. Either way, I don't think this is the hurdle, though a lot of people like to get hung up on it, me included.
But there's a million languages out there that make it drop-dead easy to write a console program. What really made VB6 kick major butt was how easy it made developing a UI application. And we're in a real pickle in terms of UI client development.
I think part of why VB worked so well is for a brief few decades, the UI paradigm and metaphors stabilized. Color depth and screen resolutions got bigger, but most of the superficial changes to apps like shading on buttons were things you expected Windows to update for you without much hassle. Now we can't agree on aspect ratios, dot pitch, whether buttons should be shaded, etc. It's hard to present a cohesive UI framework when the expectation of "what an app looks like" shifts every 2-3 years. And there's lots of different directions we could be headed:
- The return of the Desktop.
- The return of the Desktop, except you have to use something like WPF.
- The death of the Desktop, to be replaced by web "applications" using JS bridges.
- The death of the Desktop, to be replaced by cross-platform application frameworks like Xamarin's.
- The death of the Desktop, to be replaced by a platform that transcends hardware like UWP.
- The death of Windows, leaving web/x-platform/a new platform dominant.
- VR/AR destroys the concept of 'a monitor'.
Some of those are a lot more likely than others. But each requires a VB that looks a little different, or has a different kind of toolkit.
The best "new VB" will be the absolute best way to write a GUI application. Right now I don't know which of 2 or 3 of the options above will come out on top. If the industry can't settle on a UI paradigm, there's really not a way for a "new VB" to assert its role.
Yep, I call those "dark world" programming languages.Quote:
Originally Posted by Sitten Spynne
Their tooling tends to be very dismal as well, forcing GUI development into tedious sessions of hacking markup like a Web Secretary or something. Their idea of an IDE is little more than a text editor with some code-colorization and maybe autocomplete, with a menu selection to fire off a "make" script. When they do have any kind of debugger it isn't really integrated and may just be another "make then debug" menu option invoking external tools.
These are so incredibly clunky and unproductive to work with I have to roll my eyes trying to imagine how they could be popular at all. Python is one of these and how anyone can justify using it as a teaching language completely escapes me. You fuss with the primitive tooling so much you hardly have any time to focus on learning anything.
My conclusion is that an incredibly strong Anybody But Microsoft sentiment lingers among many academics. That could also explain why there are still strong pockets of people teaching based on VB6 this late in the game: VS/.Net is simply too craptastic (bloated, slow, languages encumbered with thousands of extraneous arms and legs) to deal with.
Well that was really the entire point. Try writing a Windows GUI application in plain old C or even C++ without MFC or ATL... and even with them! It required so much knowledge, was so much work, and was so unproductive... it proved a barrier to Windows adoption for line of business development.Quote:
Originally Posted by Sitten Spynne
VB came along and probably more than any other thing besides perhaps MS Office made Windows a success instead of a novelty.
Of course that did get some teeth grinding. A certain product (can you say DOS Turbo Pascal?) saw its sales plummet to nothing. So the Great Satan of Software himself decided to create a new product: Delphi (codename "VB Killer").
Nothing substantial really came of Delphi but the inferiority complex burned and burned for a decade. Old Bathless Anders finally got himself hired by Microsoft and quickly churned out VJ++, and just as quickly got Microsoft sued and they lost. So "Fire Two!" here comes .Net to try to kill VB again. That time the old Dog in the Manger finally got his way. The rest is history.
Why make things simple when you can make them complicated?
That's how american astronauts ended hitch-hiking their ride up to the ISS on a soviet firecracker and why .Net blows.
Nah, that happened because of decades of Republicans and Democrats-in-name-only pushing to dismantle the government. Now the Russian contracts are mostly being replaced by more expensive Boeing and SpaceX contracts that Wall Street makes money on.
Once again the taxpayer loses big as they shout "cut taxes" at the same time they keep on raising them. Voters are gullible fools by and large.
Omg - the NEW vb6 thread and The Donald thread have merged!
VBForums has given birth!
That or just inbreeding itself to extinction.
Don't worry, if you just hook up these compatibility hacks it'll keep working for... at least the current version.
Also I think you have a very "GUI or bust" oriented view of development, dilettante. There's plenty of programs that have no business having a GUI, and I wish .NET made them as easy as it is in those "horrible" languages. The problem isn't object-oriented programming. The problem is other languages make obscure tasks like "be an HTTP server" 3-5 lines whereas in VB I have to start with, "OK, let's open a TCP socket and listen on port 80, when I receive a connection..."
In other words, for their console-type applications, they provide VB-like simplicity. It's hard to write a GUI with them for the same reason it's difficult to bake cupcakes with a flamethrower.
for now , this idea will come true
What idea?
I think he's referring to this thread.
If I was to hazard a guess I would say spammer trying to get past the mandatory post count. Already exceeded though so preparing the ban hammer for when the spam arrives.:wave:
I disagree. I'm pretty sure he's not a spammer. Just another person hoping that somebody will write a new VB6. Seems pretty determined about it, but I also feel the enthusiasm for such a thing has faded away over the last few years.
Oh, I didn't spot that he was the OP in that linked thread. Yeah, you're probably right then.
the new vb6 , will coming soon.
my team is now writting the new C2.exe, and link.exe to the new vb6 , it will be replace the VB6 IDE .
I've heard that before, so I'll just say: I'll disbelieve it when I see it.
Actually you can already update LINK.EXE by using versions from at least the Vista SDK if not newer. I've done that. The downside is that /OPT:NOWIN98 was removed and the setting is effectively always "on" for this, so Win95/98 support is lost. It also doesn't seem to work right for DLL and OCX project types.
C2.exe is basically VC6.0's C2.dll wrapped within an EXE. I don't think it is trivially replaced by another C compiler's code generator because it has to understand VB6.EXE's generated p-code and symbol tables. You'd have to rewrite VB6.EXE's built-in incremental compiler first. That is 99% of the p-code compilation and serves as pass 1 for native compilation.
I've heard this mentioned before, and I'm curious - is there any known benefit to updating the linker? Breaking DLL/OCX compilation always made this a deal-breaker for me, but maybe there's a "killer feature" for .exe's I don't know about.Quote:
Originally Posted by dilettante
I mean, the second post-VB6 LINK.EXE (.NET 1.1, circa 2003) did add support for some neat features - like link-time code generation - but a feature like that wouldn't work on VB code anyway, since it requires cross-communication with the compiler. Is there some other improved linker behavior that makes a newer LINK.EXE worth the trouble?
I had used it for a while because it created smaller linked binaries. However this turned out to be entirely due to the NOWIN98 switch's default value changing.
Since you can set that switch via a small tweak to your VBP file there is probably nothing left to be gained from it aside from any possible bug fixes we have no way to know about.
Example:
Code:[VBCompiler]
LinkSwitches=/OPT:NOWIN98
Interesting. How did I miss it breaking DLL/OCX compilation? I've been using DLL's with an updated link (VS 2010) for some time.
And didn't notice they were broken.
I think I'll happily go back to the VB6 LINK, with the NOWIN98 switch.
Good to read this old thread from the beginning, review and realise how wrong the majority of contributors were...
You read the whole thing:eek:
I have no desire to read all those pages of posts, but I did go back and read the first couple pages. I wouldn't say that anybody was wrong, exactly. People seemed pretty much right as far as anybody could predict the future. Now, ten years later, it seems like the same arguments could be recycled without major changes. Some people would answer "TwinBasic" in a bunch of places, but overall things could be about the same.