|
In my teaching days (community college level), I created the final exams. Each problem was structured according to the Bloom taxonomy of learning. The students could bring any printed material to the exam - the course textbook or anything else.
The 'a)' question asks for 'simple facts' that can usually be copied directly from the course textbook, 'knowledge'.
'b)' is for the student to show that (s)he understands the meaning of facts, 'comprehension'.
'c)' asks the student to demonstrate how the understanding of facts is used to solve a specific task, 'application'.
'd)' asks for an explanation of a suitable breakdown of a complex situation/system, 'analysis'.
'e)' asks the student to combine various elements / principles / ... into a larger, more complex whole to create a solution, 'synthesis'.
'f)' asks for a critical, 'professional' evaluation of some technique / solution / ..., 'assessment'.
In recent years, many people put 'synthesis' (aka. 'creating') at the very top of the learning pyramid, 'assessment' (aka. 'evaluation') at the second level from the top. I tend to agree more with the original ordering: I have met lots of people - both in programming and in other fields - sprouting creative ideas like a fountain, producing lots of results, yet completely unable to do any sort of critical evaluation / assessment of either their own creations or the works of others. The other way around: In order to make a true assessment, you cannot be a stranger to the process of synthesizing a whole from constituents; you must master it quite well. Assessment is going a step further in mastering your field.
It did take some practice & experience to create exams suitable to tell how far up the pyramid a student could climb, but after a handful of exams, as I got the grip on how to phrase the a) - f), I could quite easily see where the candidate was starting to fall off, not mastering that kind of questioning. Or, the candidate was a true master in the area presented in 1a) to 1f), but didn't handle problem 2) much higher than to 2d), clearly weaker in synthesis and assessment in that area.
I am quite sure that ChatGPT would handle most problems up to the c) level quite well - although I guess I could fool it by 'trick questions' that would be handled by a human. For d) to f), it is not that difficult to phrase the problem statement so that a mechanical, robotic search would easily be revealed as a fake.
If I were creating exams nowadays, I would of course test them with ChatGPT in advance, both to learn even better to make 'trick questions' and to learn how lack of true understanding can be disguised. For the higher learning levels, I suspect that ChatGPT would reveal itself by being far more wordy, talkative, than a person with a true understanding that would go straight to the point. At least that is my impressions of ChatGPT dialogs I have seen. (I have only watched others using ChatGPT; I haven't chatted with it myself. I did have some chats with Eliza way back in 1975, though.)
|
|
|
|
|
The toughest exams I did at university were "open book" exams where we could take any printed materials (books) in with us. The exams tested our understanding of the material and ability to use it in novel ways. In other words it tested our mastery of knowledge, not the knowledge itself, i.e. our ability to think.
|
|
|
|
|
"we" are doing the same thing to "our kids" that you are doing in the Lounge: increasing methane production.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
You may be - I recommend a change of diet.
The rest of us are comparing and exchanging thoughts and ideas. I believe it's called 'intelligence'.
|
|
|
|
|
Two problems:
- I'm sure everyone here already met a very intelligent person, who, in a timespan of few days or weeks, came to two mutually exclusive, perfectly logical outcome, which changed the course of the project. Probably multiple times during the project. Some things had to be decided AND written. In History, too.
- The real professions had to be based on "repeating random facts", there is no use of a lawyer who search in the constitutional laws for the course of a divorce, nor a doctor who builds up the solution to a cold from the basics of microbiology.
Also, learning "useless" things is the same exercise for the brain as doing reps of a workout. Solving crosswords is useful against dementia, for example. Learn and reciting what learned keeps the gears running.
|
|
|
|
|
Most of the certifications I had to take were worthless rote BS. Had to memorize the properties of different optical cables. They're so expensive that you'd never just order them without making sure they were the right kind.
Minor point- Egyptian pyramids were not built by slaves. They were built by corvee labor, drafted during the flood season of the Nile. Equivalent to a tax in a non-monetary economy. They did massive cattle drives from the Delta and fed the workers far more beef than they would ever have seen in their lives. They were also paid in beer.
|
|
|
|
|
"In a stunning announcement today, a plug-in for the ChatGPT AI was released. If you have access to a 3D printer and the raw materials, you can now have the AI create for you your own children. You can select from a board range of physical and mental characteristics for your child: gender (or lack thereof), ethnicity, demeanor, intelligence, and so on. The crowd was shocked when the presenter from the plug-in company jumped into the 3D printer's material hopper, and was then reconstituted as his own child. After a few moments of confusion (an issue to be corrected in version 1.1 according to company officials) the child continued the presentation."
Software Zen: delete this;
|
|
|
|
|
They used to grind us down with pages of sums because they needed us to be calculating machines. Now they grind us down with bullshit because they need bullshitters. Now that AI really is a master of bullshit, they should leave us to be human beings.
|
|
|
|
|
Well, it's a glorified search engine with a fancy language output algorithm. But people are easily-pleased... it's interesting that it (apparently) passed the Turing test recently: it is possible, of course, to point out that the Turing test can equally as well be applied to the person administering it as to the machine being tested... that ChatGPT passed says more about the current educational level of the species than it does about the AI itself.
|
|
|
|
|
|
|
As I am getting older I am learning that we took away too much "automatism" from our life and it is not a good thing since now we are getting negative returns.
For example:
- we don't walk or do any physical activity, why should we when everything is so much easier with car, or with elevator to go to 3rd floor, or with electric chainsaw when you just need to cut through one inch thick branch... you get the point... and eventually our body and brain suffers (just started to run few years ago to try to counter this and I'm still impressed with overall gains I get back)
- we don't think deep, why should we when everything is available on Google (and via ChatGPT now). So we slowly loose our imagination since we don't have a need to use it
- we don't talk to people face to face, it's easier to automate this by using chats and all other sort of modern tools
I do like ChatGPT, it's easiest way to get answer to some fairly complex questions BUT you must validate it like any other answer you get instead of following it blindly (so it is not ChatGPT's problem)
ChatGPT will become even better, and that's not a bad thing, but we should treat it as we should treat cars - and not use it for every elephant thing, we still must try to think for the sake of thinking
However... people are lazy, kids are even more "lazier" (they are very good at finding the path that consume the least energy, have two of them... oh boy...) and I am really afraid of what ChatGPT and similar tech will to them because of reasons listed above.
|
|
|
|
|
Mirko796 wrote: we don't walk or do any physical activity
You mean like working 16 hours a day for 6 days a week bent over in a field to bring in the crops? No thanks.
Mirko796 wrote: we don't think deep,
Sorry but I have no idea what that comment means. More people can express themselves now and can do so using a vast number of ways to do it.
Mirko796 wrote: we don't talk to people face to face,
So?
When I was in school and a friend's parent moved them to another city that person was gone forever. Long distance charges and the availability of only one phone in each household guaranteed that. Not to mention that moving meant the phone number changed.
Yet now young people can maintain friendships from a young age with someone they have not seen for years. And they can make friends with people that they have never even met in person. And arrange to meet them again or for the first time when they are old enough to travel.
Of course in the good ol' days your friend might be trundled off in a wagon never to be seen or heard from again because they were killed on the way to a different town or country as they were attempting to escape the plague, war, famine or repressive regime.
|
|
|
|
|
Weapons of Mass Instruction
Read it
|
|
|
|
|
I am tired of tutorials and senior programmers which "explain" that exceptions should never be handled in lower level code.
Here is my example to end all examples why you do need to catch exceptions sometimes in low level code:
We have a component for importing millions of records of data from a delimited text file, process it and store it in cleaned-up form in a database.
Now, data in delimited text files is "quite" clean but very occasionally it is not, and we want the import to stop and indicate WHICH column. So we can fix the import data, or the thing which generates it.
Let's say that's a date column and we have Convert.ToDateTime() and there are 10 date columns in that structure - it will throw an exception allright which bubbles up but will be the unhelpful
String '184' was not recognized as a valid DateTime .
So - catch the exception, add row and column info and then re-throw. Really, anyone who sees this as wrong must be working with mickey-mouse applications where you never have to sift through millions of records to find the one datum which is wrong. Isn't it?
Out of this "purity" of exception handling we get abominations like the SQL Server error message "String or binary data would be truncated." (I know it's finally handled as of SQL Server 2019, but it's been around for decades.)
|
|
|
|
|
Depends what the source of the bad date was: if it's the user, then I'd be processing that at the point where he said "Enter" so lower level code never meets the problem - and I'd be using DateTIme.TryParse or TryParseExact instead anyway so the exception would never occur.
Personally, I handle errors as close to the "source" as feasible - provided I can handle it. If it's an error where it makes sense to handle it, do: your error message is indeed unhelpful, so I'd wrap it as an inner exception with a "The database was not updated because ..." message and throw that to give relevant info to higher code. If "this code" can't handle it, then let a higher level do it - but give them info to help them much as you are.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
nepdev wrote: catch the exception, add row and column info and then re-throw.
So really, you are not actually "handling" the exception in the lower level code, you are in fact repackaging it and letting the higher level code deal with it. I think the definition of "handled" would usually be that it is dealt with and the higher level code never knows about it.
Now, if your example was, we "handle" the exception at the lower level by logging it and let the processing continue, that might be a wee bit better. 
|
|
|
|
|
Yes, adding detail and rethrowing is not "handling".
|
|
|
|
|
Adding detail *is* important at the lower level exception. Even if it can't be "fixed" at the lower level, at least provide the detail to indicate where the error really is. I've seen so many cases where staff has to stop and sift through files or tables to get to the one record that caused the problem. Staff work is expensive. If the some key data is logged (or rethrown) and the program can move on, then it will save plenty of time.
I think he's complaining that people/tutorials advocate for simply coding a "No Can Do" exception message with no context about where to find the problem.
|
|
|
|
|
Peter Kelley 2021 wrote: Adding detail *is* important at the lower level exception
However the point in the previous point is not about that.
It is about that wrapping it and then throwing it again is not handling it - as it said.
|
|
|
|
|
I agree. When doing what seems to me some sort of batch processing, log the error and location then carry on.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I agree.
No method knows how deep it is going to be.
Catch an Exception, add detail, and rethrow as necessary if you can't handle it.
Additionally, don't try to validate every value if you're just going to pass it on to another method anyway. Having a whole stack of methods checking and re-checking a value is a waste of time.
|
|
|
|
|
I feel a contradiction between your first and third lines. Checking input is a requirement in my workplace (financials). I think everybody here more than once burned itself when said procedure got called from other procedure than the original caller procedure in the design.
Which leads to the "do one thing" theory - was it dissected into a chain of procedures just to reach purity? Aesthetics?
|
|
|
|
|
nepdev wrote: I am tired of tutorials and senior programmers which "explain" that exceptions should never be handled in lower level code.
Your sources are flawed.
nepdev wrote: So - catch the exception, add row and column info and then re-throw
However that example would certainly not seem like a good way to prove your point.
Especially since you are said "millions" of rows and that you know that you expect some of the data to be flawed.
It would seem to me that you would want to continue. So you report the bad row and then continue. No exception should be thrown.
As well you might even to decide to attempt to clean some bad data. Especially after looking at the prior reported problems.
|
|
|
|
|
Exception handling is an alternative to solving the source of the problem or finding an alternative solution.
For example, "cleaning" data at the source and adding to a suspense file is usually preferable to throwing exceptions in the back end.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
