|
Rick York wrote: I despise everything about dot nyet.
I'm curious about why? Particularly since I have quite the opposite reaction.
Latest Article - Azure Function - Compute Pi Stress Test
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Just one word: Mickeysoft
.Net can never be so good that they get me to marry them and then let them move in and do whatever they like.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
CodeWraith wrote: just one word: Mickeysoft
Subjective religious reasons, then. Any objective reasons?
|
|
|
|
|
OriginalGriff wrote: Some languages - like C# - are strongly typed for a reason: to catch errors early.
I found going from Object Pascall (Delphi) to C# was pretty easy, since they are both strongly typed. Of course going from ALGOL to PASCAl was also fairly easy, but going from FORTRAN to ALGOL was painful.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
I also have had to fix problems such as the MM-DD-YY problem you described.
Strong typing often causes as many problems as weak typing because people want to find a solution for their problem. I'm thinking along the lines of a "definable" strong type conversions. Using arithmetric conversions such as integer to character, I would simply like to say "string S = i" having previously declared "i" as an integer. Then, add optional meta-data such as format.
Regarding pointers, C++ pointers has made debugging difficult. And having to cast causes even more confusion. I'm thinking the majority of pointer and casting problems are caused as a result of less experienced or lazy developers trying to find a quick, workable (in most cases) solution to their problem.
I'm just wondering if there isn't perhaps a better solution.
|
|
|
|
|
I disagree - they are a different type of problem. String typing reduces problems that can be located at compile time, while your weak typing problem is because the developer hasn't thought about the code sufficiently. If that forces him to look at what he's doing instead of assuming that the compiler will do the right thing, then that improves the code and reduces the chances of bad data.
You make typing mistakes, I make them - we all do. The more that the compiler can pick up instead of assuming that it's correct and blindly converting the wrong data the better, no?
string s = id; bad if you actually meant to do this:
string s = IansName;
Why is it such a problem for you to spell out what you want the compiler to do?
Adding formatting defaults and suchlike makes it more confusing if the developer doesn't realise what format is being used ... which is why you get dd/MM/yy and MM/dd/yy confusion because different users use different defaults!
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
What I want is for my local 5-Guys burger joint to stop burning the bacon on my double-bacon cheeseburgers.
|
|
|
|
|
I concur - but I skip the cheese part.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
...All I Want[^]
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OMG!! Pass the mind-bleach!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
OK - Mind Bleach[^]
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I knew what is was going to be and yet I still went there!
You b&^$@$*&!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Took your mind off of Melissa Lynn tho' ...
My work here is done.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
...All That She Wants[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Agreed, and also skip the burger part.
What's wrong with a plain bacon sandwich?
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
My local one gets it perfectly crispy without burning it.
|
|
|
|
|
rjmoses wrote: I do a lot of development, migrating, porting, etc., in different environments, different systems, different languages, different versions,....get the idea? I have specialized over the years in doing weird stuff.
Good! I got a PHD by asking questions about things that everyone else assumed, so that seemed weird at the time, but I was right to question the assumptions, it turns out they were wrong.
The weird problems are the most interesting.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Never neglect the "trivial" roots of an equation.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Weird problems are the most fun, most satisfying, but usually take more time than the budget allows.
Result: People take shortcuts because somebody is crawling all over them to "get the job done".
I, like many people, am inherently lazy. But I work very hard at being lazy efficiently. I do not like solving the same problems over and over. I do like solving a problem--once! The second and subsequent times are a waste of my time.
I will never, ever, buy a self-driving car with the current state of software development.
|
|
|
|
|
My ex-wife has a big endian.
A REALLY big endian.
In fact, it's so big, she counteracts the effect of the moon on local tide tables.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
When she sits around the house, she sits aaa-rrrr-ooo-uuuu-nnnn-dddd the house.
|
|
|
|
|
and THAT's why she's not getting your mustang, the shocks won't hold up.
|
|
|
|
|
Once you start writing significantly sized software automatic conversions are the last thing you want. It's a mine field of errors waiting to happen, IMO.
As is often the case in line, you can sort of pick one, easy or good. You can't really have both unless it's a fairly modest undertaking. When it gets serious, the old saying of measure twice, cut once really applies. The time you spend being very specific to the compiler about what you want to happen will save you endless woe.
This is one of the things that really makes me shake my head at modern C++ where people are using 'auto' all over the place.
Explorans limites defectum
|
|
|
|
|
rjmoses wrote: What's your thoughts?
After pondering this post all day, I finally came up with a response.
IDIC[^] you must learn and become one with.
(Argh, a Star Trek and Star Wars reference in one sentence.)
Latest Article - Azure Function - Compute Pi Stress Test
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
A colleague was just complaining about a new language+library that he was using for big data.
The complaint:
Too many "magical" conversions were taking place under the covers. Often processing the data in non-optimal ways, and not an easy way to force better ways to process it because of poor library design.
Per dates and formats. Dates/DateTimes in codes should be some sort of numeric type (possibly wrapped) and always in UTC. As someone else mentioned, display of dates (including timezones) should be a user preference or a replaceable component that mimics being a user preference.
|
|
|
|