Wordle 1,158 3/6 ⬛⬛🟨⬛🟨 🟩🟩🟨🟨⬛ 🟩🟩🟩🟩🟩 Ugh, I got lucky but almost blew my second guess. Put the same wrong letter in the same position.

charlieg wrote:

The ultimate goal is to avoid errors.

Yep! And I agree with you that magic numbers run counter to that, since there's no visible, verifiable logic within them - you just have to somehow know that it's correct. When I was learning 68000 assembly in the 1990s, I'd read freely-available source code and see moves to and from arbitrary memory addresses for device I/O etc, and wonder how often people accidentally used the wrong address (or one that may only be valid if your machine has exactly 512kb RAM). Where possible I'll try to push back on the inscrutability a bit, like defining

SECONDS_PER_DAY

as

60*60*24

instead of

86400

.

Extracting magic numbers as named constants is usually a good idea, but orthogonal to the question of whether an underscore separator is helpful or not. It absolutely is helpful if you're dealing with number with mure than 7 or 8 digits. There's a reason we use commas (or periods in continental Europe) to break numbers into groups of 3 digits: it makes it much more obvious when a digit is missing (or erroneously present).

Yep! I've been out of a job for over a year, but still love coding. Woke up early and knew I wouldn't get back to sleep, so I came down before 5am and started looking at some SAT-solving code. Took a little diversion to test something out in the K language (a somewhat obscure descendant of APL). It's good to unplug periodically, but... this stuff is fun!

I was tasked with "tidying up" a killer demo hacked up by a data scientist on our team during his holidays. After looking at the single 15k line Javascript file he produced, I suggested we rewrite the demo frontend from scratch since it was going to be difficult to work on (even though it looked really polished). That suggestion was shot down as unnecessary engineering, but when I looked closer it became clear that he'd "borrowed" a complete demo published by another company -- a single minified Javascript file -- and swapped out of a few pieces so it called his own prototype backend running on a laptop (that bit at least was entirely his own work). At that point I suggested this might be a good reason for us to proceed with the frontend rewrite, and that I wouldn't be comfortable putting my name on another company's pilfered and tweaked demo. The DS seemed relieved and immediately agreed. He was a good guy, but probably crumpling under delivery pressure from management, and he never really intended for an internal proof-of-concept to suddenly become a user-facing feature of the site, but by then it was hard to backpedal until I forced the issue.

Not sure if this was already mentioned in one of the other responses, but you have E and A in the wrong order for the sharp key signatures. A has 3 and E has 4. I learned the sequence of sharps (aka circle of fifths) back in piano classes many years ago as "Father Charles Goes Down And Ends Battle". Conveniently, you can reverse the phrase to get the order of flats (ie circle of fourths) and it still makes sense.

My C64 was a C64C. I really loved that machine, although we got it very late in the machine's life (around 1990). It was amazing because you were dumped straight into the Basic interpreter within a second or so of flipping the power switch. Even though it was a terrible Basic dialect, it was the beginning of a lifelong journey of learning actual magic. A couple of years later, we got an Atari STFM with 512 kb of RAM -- a pretty nice upgrade. Between that and the 4MB STFM I scored a year or so after that (complete with a disk box chock-full of pirate menudisks), I got a taste of programming in GFA Basic (and the less elegant STOS Basic), 68000 assembly and C. Good times!

Munchies_Matt wrote:

As you say humans can detect the key, if they are musicians, because of the mood, or feel of a song. How do you teach a computer to understand mood? :)

Indeed, this is difficult for computers, but it's easy for us and therefore not the problem we need them to solve -- accurate transcription (of heavily polyphonic music) is very hard for us and that's where we need help from the machine.

There have been many attempts to create software that can accurately transcribe polyphonic music, going back at least to 1998 (WidiSoft). All of the ones I have tried have produced quite bad results, with a mess of very short notes and lots of "noise" notes that it's falsely detected from overtones or whatnot. There's a pretty comprehensive list of existing software here. As it's still a research problem without a general satisfactory solution, you can also find lots of papers on Google Scholar[^]. I tried a couple of programs released with research papers with mixed results (mostly on piano music, but some chip music too). Let me know if you find something that works well!

kholsinger wrote:

As hinted at above -- it's not even as simple as identifying the pitch (frequency) of the note of a particular instrument. For example, a particular pitch could be considered a D# or an Eb, depending on the context.

If the machine could just identify the pitches of each note, that would be a massive leap forward and would simplify transcription greatly. Fixing up enharmonic equivalents later wouldn't present any kind of meaningful problem to the user and is a piece of cake compared to trying to transcribe a whole song by ear. That said, all automated transcription software I've tried to date has indeed done a really bad job at rhythmic dictation and tends to be produce a mess of rapid notes. This is more time-consuming to fix and badly obscures understanding of the music.

Working out the key is a trivially simple task that the human can do, either as an input to the program or later when editing its output. In fact, since the computer already knows the *pitches* of every note, a good heuristic would be to go through all keys and see which produces the least amount of accidentals in the resulting score. The really hard bit, as you pointed out first, is isolating the sounds of different instruments.

Personally I consider "software engineer" to be a case of buzzword bingo, just like "software developer" or "rockstar". Before these fluff phrases came into existence, "programmer" implied not just syntax and "details", but also spending time considering the big picture. Honestly, since when did programming ever *not* involve "designing and understanding complex mechanisms. The architecture. The guts of the machine"? It *always* meant that. Don't let recruiter-speak diminish the meaning of "programmer".

Good point! I must have read more than ten of the Discworld books in the space of a year or two as a teen in the mid 1990s. Each one struck me as more enjoyable and more interesting than the first Harry Potter book (admittedly, the only one of the series I've read... aloud, to my daughter, so a very different reading experience). Speaking of HP... no H.P. Lovecraft? No Journey to the Centre of the Earth? No Around the World in 80 Days? No Chronicles of Thomas Covenant? Well fine... I'm a bit embarrassed to say "23" :sigh:

NormDroid wrote:

Ever heard of a search engine?

Yes... I got no results from the search box in the CP forums, having figured it would appear there since it was the subject of the CP email. Didn't figure it would be the verbatim title of an article on another website. Thanks for the link.

PIEBALDconsult wrote:

Using both hands is inefficient. Do more with less.

Dare I ask what the other hand should be (simultaneously) used for? :^) The article did resonate with me tho -- I'm always amazed at a colleague of mine who, despite being an excellent programmer with many years of experience, still looks down at the keyboard and mostly uses two fingers to type. But then, I suppose writing programs at 100 wpm is a bad idea... especially if you're using a language like J, K or... APL :omg:

This was the subject of the latest Insider email, but to what was it referring? I couldn't find an article that seemed related to the subject, but maybe I've not had enough coffee this morning... :java:

mikepwilson wrote:

It certainly sucks alright. But you're gonna have to just go ahead and get used to it.
 
There's absolutely no reason for a company to respond.
 
You have to approach each morning as if it's the first one 'on the market'. No interviews, phone calls, email exchanges mean anything until you've got signed paperwork and someplace to report and start work.

Agreed with all but the middle statement. There is quite a good reason for a company to respond -- so that they don't tarnish their reputation in the community. If it gets around that a company has rude HR or fails to follow up on interview outcomes, surely that will have a negative effect (unless the company is extremely attractive for other reasons). Absolutely spot on about the last thing though; nothing said during the process can be relied upon until a contract is produced and signed. And even then... :^)

Nish Sivakumar wrote:

So, what does this leave us with? Well folks who can’t code, and whose English expressing abilities are severely lacking. While it sounds unfair, it’s best if these people try and work on at least one of these skills before venturing out to these sites, unless they possess really thick skins and are prepared to learn and improve amidst a showering of insults and abuses.

Can't say I agree with this. How many times have you said to yourself "hmm, I need to use some kind of statistical tool to solve this problem, so I'm going to go away and 'learn' statistics before approaching the problem"? Or "oh, I've never used non-blocking IO before, I'd better go and learn all about it before trying it out". In my experience, learning by jumping right in is usually better, as it constantly tests you and forces you to question and improve your understanding. We spend our whole lives learning to express ourselves, both in human and machine languages, and we attain perfection in neither (because, of course, there is no such thing). I'd say, better to jump in now and look like a fool sometimes than to refrain from participating until you feel "good enough", which may never happen. And those times when we make a basic mistake publicly and feel like fools - aren't they the most educational experiences? Also, what better way to develop that thick skin than by suffering those insults and abuses that inevitably occur online? :)

Mike Winiberg wrote:

It seems to me that the risk of dropping or replacing Java needs to be assessed against the risk of the incoming system being more vulnerable or less mature...

Indeed, it's so easy to throw the baby out with the bathwater when these decisions are made (often by people without the technical expertise to do so). It's a similar problem to that faced by countries which undergo a coup or revolution and replace the government with a completely new one - historically, the new government has frequently been an utter disaster. And going back to software, I read a nice article a while ago discussing our tendency as programmers to point at dirty old "ball of mud" projects and say "oh what a mess that is, let's throw it out and start from scratch, having learned from those mistakes". But then it turns out that most of that "mess" was there because you (or whoever wrote the code) had discovered and fixed many bugs and corner-case behaviour. So the new "clean" code starts out simple, but as these corner cases are rediscovered, the same thing happens all over again. Two years later, you've moved on and the next programmer arrives, looks at your "clean" codebase and says "tut tut, what a mess... maybe we should..." ;)

Nice! I much prefer this lighter, clear style. :thumbsup: