Visual Basic needs more credit
-
When dealing with a database, sometimes there are bad records. I meant for these try catches to be this way, as I don't care at this point why there would be problems in the data, all other errors are handled.
You know, you could have avoided a whole lot of discussion just by adding a comment saying that. I too sometimes add error handling code that I know I don't really care about, just to make a point that I did consider the possibility of that error. And, of course, if someone later adds to the code, he may need to reassess if the error can really be ignored - if the (emty) error handling code is already there, then it's much less likely he'll forget to deal with it. :)
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
This is only for displaying data. Apparently you want the user to wait for typos for each action, instead for a daily report of problems you are not god, you do not know every angle to program.
Colborne_Greg wrote:
Apparently you want the user to wait for typos for each action,
Apparently I'm talking against a wall and wasting my time. If you trash the users' database just tell them to ignore the error and move on.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
I do miss the with operator. I have cases where it could save hundreds of characters and make it way easier to read. Don't listen to the C# purists. :zzz:
There are only 10 types of people in the world, those who understand binary and those who don't.
In the time of autocompletion editors, less typing is no longer a valid argument.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
visual basic is easier for people with less skill
I agree. So if you're intent on hiring people with low skills, VB is a reasonable choice. Most hiring staff want people with high skills though...
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
That's why visual basic is great. I don't need to hire anyone who thinks they are a programmer. Its a tool that is easy to train people and allows me to pay them next to nothing.
Colborne_Greg wrote:
allows me to pay them next to nothing
If you had written that from the beginning, I'm sure everone agreed. :-D
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
I agree. So if you're intent on hiring people with low skills, VB is a reasonable choice. Most hiring staff want people with high skills though...
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Do you know what its like in an agile environment with highly skilled programmers that all think they are the best and try to leave there mark on a program? Not only do they cost more, they wasted extra hours, and broke the conditions of the client. Most of the places that want high skills are getting over qualified people for simple tasks in a lot of cases, there is so mush wasted talent that could benefit from a team of code monkey's, these people carry out the thoughts of the skilled programmer. If skilled programmers came with code monkey's I would hire them ;)
-
You know, you could have avoided a whole lot of discussion just by adding a comment saying that. I too sometimes add error handling code that I know I don't really care about, just to make a point that I did consider the possibility of that error. And, of course, if someone later adds to the code, he may need to reassess if the error can really be ignored - if the (emty) error handling code is already there, then it's much less likely he'll forget to deal with it. :)
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
The code was a quick attempt at a just works client. My laziness just so happened to spill over into this thread ;)
-
Colborne_Greg wrote:
Apparently you want the user to wait for typos for each action,
Apparently I'm talking against a wall and wasting my time. If you trash the users' database just tell them to ignore the error and move on.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
I am using Unidex and not a database, Unidex does not have null issues.
-
Having or not having a specific operator can hardly be an argumant in favor of any language. There are thousands of keywords other languages provides that VB doesn't have! Besides, Pascal also has
with. And I already told you that much in a different thread. :doh:GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
I always forget about pascal, a language I learned but never really wrote anything in.
-
Do you know what its like in an agile environment with highly skilled programmers that all think they are the best and try to leave there mark on a program? Not only do they cost more, they wasted extra hours, and broke the conditions of the client. Most of the places that want high skills are getting over qualified people for simple tasks in a lot of cases, there is so mush wasted talent that could benefit from a team of code monkey's, these people carry out the thoughts of the skilled programmer. If skilled programmers came with code monkey's I would hire them ;)
It all depends on the kind of work at hand: I've been working with high skilled programmers for 30 years, and my experience is quite the opposite. The applications were all quite large and complex, or had highly innovative and complex functionality, or both. Of course if the job at hand is more mechanical in nature and doesn't require the coder to really think out of the box, then a skilled programmer won't be happy, and will quit, or not even apply to the job in the first place.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
The code was a quick attempt at a just works client. My laziness just so happened to spill over into this thread ;)
It's exactly that 'just works' mentality that needlessly causes hours and days of maintenance effort when it comes to figuring out what a buggy function does, or what it takes to adapt it to a new functionality without introducing regressions. If you care about the state of your program in 6, or even 2 months, then you should care about comments and think beyond 'just works'. Not saying or implying that this is your professional style of coding, but it is all that we see here, so don't be surprised if people react and respond accordingly.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
I always forget about pascal, a language I learned but never really wrote anything in.
That was just an aside. Every single object oriented language doesn't need and doesn't want a
withkeyword! If you need to perform a series of operations on a single object, then you write a method for that! You won't even need the introductory '.', and you can just call the method from different places without having to copy the original code (including the errors therein). That's a lot more elegant than your example, and far better readable because the implementation will be within the context of the object class, rather than in the context of some arbitrary function that just happens to use it! I do realize that VB has classes too - but that is all the more reason that it shouldn't even have awithstatement: it just leads to code that is harder to maintain than writing a class method. Have you never wondered why an old language like Pascal has it, but none of the newer ones? Not even the newer languages by Niklaus Wirth himself (Modula, Oberon) have it! If you must discuss the merits ofwith, shouldn't you instead ask why its inventor, Niklaus Wirth, and (almost) all other designers of modern programming languages abandoned it?GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
I am using Unidex and not a database, Unidex does not have null issues.
When you're trying to access data from any source that is not in your application memory already, then you should consider the possibility that the data connection might get corrupted for unexpected reasons. Depending on how the connection is working, follow-up requests may clog the input queue and lead to the application blocking, which is just as inconvenient - or even more so - as an app crash! Not dealing with exceptions and at least trying to find out if it reoccurs is just a recipe for trouble. If nothing else, it's a security hole waiting to be exploited. At the very least you're potentially wasting a lot of time waiting for responses to data requests that never arrive. If the user wants to display 5000 data records, and your loop gets a 'connection timed out' exception every time, just how long do you think the user is happy to wait for a response?
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
When you're trying to access data from any source that is not in your application memory already, then you should consider the possibility that the data connection might get corrupted for unexpected reasons. Depending on how the connection is working, follow-up requests may clog the input queue and lead to the application blocking, which is just as inconvenient - or even more so - as an app crash! Not dealing with exceptions and at least trying to find out if it reoccurs is just a recipe for trouble. If nothing else, it's a security hole waiting to be exploited. At the very least you're potentially wasting a lot of time waiting for responses to data requests that never arrive. If the user wants to display 5000 data records, and your loop gets a 'connection timed out' exception every time, just how long do you think the user is happy to wait for a response?
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Unidex manages the problems, its a connectionless state, serialized, time stamped, with automatic collision detection, that produces a daily report of user errors. It even comes in a marshalled version with a web api for web services. 100% of SQL related errors and practices are gone.
-
That was just an aside. Every single object oriented language doesn't need and doesn't want a
withkeyword! If you need to perform a series of operations on a single object, then you write a method for that! You won't even need the introductory '.', and you can just call the method from different places without having to copy the original code (including the errors therein). That's a lot more elegant than your example, and far better readable because the implementation will be within the context of the object class, rather than in the context of some arbitrary function that just happens to use it! I do realize that VB has classes too - but that is all the more reason that it shouldn't even have awithstatement: it just leads to code that is harder to maintain than writing a class method. Have you never wondered why an old language like Pascal has it, but none of the newer ones? Not even the newer languages by Niklaus Wirth himself (Modula, Oberon) have it! If you must discuss the merits ofwith, shouldn't you instead ask why its inventor, Niklaus Wirth, and (almost) all other designers of modern programming languages abandoned it?GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
I has everything to do with being able to get full words onto the screen and not have to repeat them, there is no compiler benefit. There is a psychology difference in the mind of the programmer that is more acceptable to human error and overall costs less while getting to the result faster and cleaner then any language.
-
It's exactly that 'just works' mentality that needlessly causes hours and days of maintenance effort when it comes to figuring out what a buggy function does, or what it takes to adapt it to a new functionality without introducing regressions. If you care about the state of your program in 6, or even 2 months, then you should care about comments and think beyond 'just works'. Not saying or implying that this is your professional style of coding, but it is all that we see here, so don't be surprised if people react and respond accordingly.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
We don't spend time on bugs, we use Unidex.
-
It all depends on the kind of work at hand: I've been working with high skilled programmers for 30 years, and my experience is quite the opposite. The applications were all quite large and complex, or had highly innovative and complex functionality, or both. Of course if the job at hand is more mechanical in nature and doesn't require the coder to really think out of the box, then a skilled programmer won't be happy, and will quit, or not even apply to the job in the first place.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
My family owns a factory warranty center for Panasonic, growing up I was trained on programming microchips. When I deal with people and they tell me they know computers my first thought is to think they are full of themselves.
-
I has everything to do with being able to get full words onto the screen and not have to repeat them, there is no compiler benefit. There is a psychology difference in the mind of the programmer that is more acceptable to human error and overall costs less while getting to the result faster and cleaner then any language.
What you say are exactly the things I didn't bother pointing out in favor of using class methods, and against the with statement. But if you're not familiar with basic OO concepts, then there's no point discussing this any further.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
We don't spend time on bugs, we use Unidex.
Which nobody here appears to know, and on google turns up blank. Meaning the only reference to your coding is the lazy sample you gave us. P.S.: If you didn't find bugs, you didn't test enough.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
Unidex manages the problems, its a connectionless state, serialized, time stamped, with automatic collision detection, that produces a daily report of user errors. It even comes in a marshalled version with a web api for web services. 100% of SQL related errors and practices are gone.
Now you're sounding like advocating some religious sect. I mean, nobody here has ever heard of Unidex, witnessed it's superiority, or revels in the light of its magnificence. If it sounds too good to be true, it isn't.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)