>> "The requirements changed three days before launch."
> Of course they did! What happens when requirements change inside the launch window?
What answer is wanted here? "Moving forward, we'll ignore the VP of Marketing's last minute 'must haves'"?
1,283 karma · joined July 25, 2013
>> "The requirements changed three days before launch."
> Of course they did! What happens when requirements change inside the launch window?
What answer is wanted here? "Moving forward, we'll ignore the VP of Marketing's last minute 'must haves'"?
I appreciate that there is a _ton_ of different experiences out there when it comes to solving problems, but I _have_ encountered exactly the case I was describing, which is what led me to my original question. Isn't the fact that it was a checked exception that led you to "consider retrying a network failure, you immediately need to start thinking about distributed systems failures, idempotency, and all that good stuff" worth it as opposed to an unchecked exception you may not realize is being thrown?
Can you explain why this is pointless? In my mind, this being a checked exception would hopefully be a hint that I should think about this failure-case and make an explicit decision whether to handle it or not. Network connection failed? Maybe I retry. Maybe I store that data somewhere else as a fall back. Isn't this similar to Go programmers needing to check if err is not nil?
{a 1 b 2}
Should the above be serialized as a dict, a list, or a string (ignoring the various possibilities of treating ints as strings themselves): {"a": 1, "b": 2}
["a", 1, "b", 2]
"a 1 b 2"[0] https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/tclli...
I think it may be important to note _when_ to redo this. I started off this way, but after working with a guitar teacher (a Berklee graduate), he recommended that I continue on with the song and return to the problematic parts afterwards. If you constantly stop at the problematic parts to replay them and get it right, you'll have no idea what other parts you'll have trouble with further into the song until much later. In addition to that, being able to move on and continue playing the song after making a mistake is an important skill itself. If you build that skill, it's usually only other musicians that will notice -- a regular audience won't.
What's your take on it?
What's left unspoken here, and something I've brought up in other threads that have mentioned Ruby + LLMs, is that they continue to struggle _comprehending_ Ruby (and Rails) style code. In a fresh project, agents writing code for humans to review is a solid approach, but when the codebase grows and the project starts suffering from the downsides of dynamic typing, you're not going to be able to lean on that LLM to aide you in refactoring.
I work closely with Northeastern CS students (via co-op program) and haven't heard anything but negative opinions about Racket.
>...I’m not entirely sure what that looks like yet, but things like this are a step in that direction.
This made me stop and think for a moment as to what this would look like as well. I'm having trouble finding it, but I think there was a post by Joe Armstrong (of Erlang) that talked about globally (as in across system boundaries, not global as in global variable) addressable functions?
I’ve seen this sentiment expressed numerous times and have never found it to be true in my own work (e-comm), do you mind mentioning _what_ type of domain your web apps are in?
Edit: or if not domain, what do you mean by “web arena”
edit: I suppose this is different concern than a true SPA, but as another sibling comment points out, its just a matter of time before routing makes its way into the front-end as well.