gered

Exactly this. If you were using the exact model today that 6-12 months ago people here were telling you "absolutely does not make this kind of mistake anymore" they'd tell you the same thing again, just replacing $OLDER_MODEL with $NEWER_MODEL. Why did $OLDER_MODEL not make this mistake 6-12 months ago, but it does now? The answer to that question is obvious, but AI-bros cannot understand that.

It's basically impossible at this point to take these people seriously anymore.

The most exciting thing for me about this phone is the physical size. It's not a "phablet" like every other phone these days, it's basically Nexus 4 sized (perfect size for my big hands) which means easy one-handed use.

Not sure if I will actually get one since my Pixel 4a 5g (w/ LineageOS + microG) is still going strong, but I will admit that I'm tempted by this.

The latest Qwen models (including 3.8 27B) do still support FIM-style in-editor code auto-completion if that's what you're looking for. I wouldn't want to use a large dense model like 27B for such a task (since FIM-style auto-completion really works best with low-latency responses), but it works.

That's great! There's nothing wrong with that!

But what you're saying is NOT what the person I was responding to was saying, 'nor was it what I was responding to. I don't know if you read their post or not before replying to mine. Frankly, I'm not even sure if you even fully read my post if this is what you're zeroing in on ...

This is a very narrow view of the situation. There are any number of reasons why some people may prefer working from an office.

Take myself as an example. I live alone, in a small apartment. My home "office" is a corner of my living room. I'm not "rich" and unfortunately cannot currently get a place big enough to have a dedicated room for an office. As a result, over a long period of time of working from home I end up getting the feeling that I'm living at work. In general, I prefer a strict home-vs-work separation, so going to a physical office elsewhere to work over the longer term helps me.

Other reasons include that some other people who prefer working from an office outside their home may just in general like the in-person social aspect that comes along with it.

It's shocking to me to now see a narrative like what you're trying to push that labels people who want to go to the office as terrible people. Jeez, wow!

It's really sad, but yes, this is what I ultimately ended up doing too. There was no way to configure the filters to very closely approximate what the feed was showing previously that I could find. The new algorithm always seemed to want to throw stuff at you that was slightly outside the bounds of what you were specifically following (clearly done to help you "discover" something else that you may be interested in, treating it as if this was a social media platform instead of a coding platform ...).

Hello! First time posting in one of these threads. I suspect it'll just get lost in here, but who knows!

I'm a developer who has been writing code professionally for ~18 years, but in total including my self-taught years as a teenager, etc, I guess it's almost 30 years of slinging code at this point.

  Location: Toronto, Canada
  Remote: Yes (EST timezone), also perfectly willing to do hybrid and on-site.
  Willing to relocate: No
  Technologies: Java (Spring / Spring Boot), Clojure/ClojureScript, Docker / Kubernetes, SQL (Postgres, MSSQL, Oracle, ...), Full-stack Web Dev, Backend Web Services, DevOps (Jenkins, Bash, Ansible)
  LinkedIn: https://www.linkedin.com/in/gered-king/
  Github: https://github.com/gered
  Website: https://blarg.ca/
  Email: gered@blarg.ca

These days I'd consider myself much more of a backend / web services developer. I've done plenty of full-stack web development over my ~18 year career, but over the past ~8-10 years almost all of the frontend code I've written has been ClojureScript, so I feel I'm totally out of the loop on what the JavaScript / TypeScript world is doing. And I just prefer backend stuff in general these days.

On the side, I work on hobby projects mostly relating to game development (see my Github profile). These projects are usually in Rust or C/C++.

Thanks for reading!

Yup. It's absolutely crazy to me to see the amount of people who are apparently doing hiring telling others here in the comments (and elsewhere on HN, etc) that they should "grind leetcode" while also NOT admitting that this is absolutely stupid. Like I'll give you a pass as an interviewer / hiring manager if your hands are unfortunately tied and you can't change your companies hiring processes.

But if you're an interviewer or hiring manager who is telling people to "grind leetcode" because you legitimately believe this is a good way to find good talent ... you need your head examined. All you're doing is filtering for people who've grinded leetcode long enough to memorize solutions. This has ZERO correlation to software development ability.

While that is obviously a detractor that I would agree with, how much it affects you will vary from person to person.

Again, just myself as an example, I've been somewhat surprised over the years how little I've actually needed a super key.

On Mac OS, my preferred keybindings was to have Command bound to both left and right Alt keys, Ctrl kept as the left Ctrl key, while the right Ctrl key was rebound to Option/Alt. Some people also like rebinding the usually-useless Caps Lock key but I am one of those weirdos who doesn't like doing that.

I've moved back to Linux over the past couple years and haven't found the need to do any rebinding to get a Super key on my keyboard at all.

Your mileage may vary!

> I don't see any rational argument for a Model M in 2023. There are so many options in keyboards that are more modern, quiet, well built, compact and yet feel nicer to type on.

This is a highly subjective take. Just taking myself as an example, an original Model M feels far nicer to type on to me personally than any of the other modern mechanical keyboards that people often recommend.

There are absolutely rational arguments for a Model M. Just as there are rational arguments for other keyboards too. You just have to try to look at it more objectively and try to match to people's own unique personal preferences.

> I've never had a test come later. 15 minute interview call to make sure the high level details are correct (pay, location, physical office vs. Remote, etc), and then I am sent an interview test.

Depends on the company. My personal experience has luckily been (so far) that more companies I've interviewed with who do take-homes at all have given them later on in the process.

I suspect with the current job market situation given all the recent layoffs that things will probably start to shift for those companies that do take-homes, where they'll probably start giving them to candidates at the beginning of the interview process, as they'll probably see it as an easy filter for themselves. Ugh.

I don't think that's a "different opinion" at all! :-) I look at it the same way basically.

See, I take a bit of a different view in the example you've given. Like, if I got rejected because I seemed "too excited about my personal side projects" I'd come away from that thinking "if that's really their take away, I'm kinda glad I don't work with them!"

You're right that the conversational interviews (just like any social gathering, really) have their own rules. But I think the most important thing you can do during those interviews is to just be yourself. After all, you want them to get to know you, just as you want to get to know them, right? How else can you each be sure that you're a good fit for each other? If they reject you for something you said that is true but that they just didn't like (e.g. a difference of opinion on something), or they nitpicked some little thing you said even though the rest of the conversation went smoothly ... well, in my opinion, you're better off.

I mean I agree with you on this, but the idea that you can gauge a person's skillset through conversation (gasp!) and talking about your craft and details about past projects, etc seems to be totally lost on people today.

It's been surprising to me to read through the comments posted here and seeing how most people seem to really despise take-home assignments during the interview process.

Speaking as someone who absolutely hates live-coding something during an interview (unless, maybe, by chance it's a practical exercise ... something like "build up this simple CRUD web service" ... not "solve this leetcode problem" ... but this is pretty uncommon in my experience, unfortunately), I rather like take-home assignments. As long as they don't take any more than 1-3 hours. I've been in situations where I've declined a take-home assignment that was given to me where I estimated it was going to take 10-20+ hours. No idea why any company would think that is reasonable.

For myself, what I hate is when the take-home assignment comes first. Like, before you talk with anyone at all, or maybe immediately after you did the 15 minute HR/recruiter screen. If I get a take-home assignment at that point, I decline.

There's no denying the fact that a take-home assignment is a large investment by the candidate on this random chance to get the job. I'm not willing to make that investment unless I've gotten a chance to talk to at least _some_ of the people I'd be working with at a company to better gauge what the situation is and whether I think it's a good fit for me. Even a 15-minute HR/recruiter screen is not going to do that. So yeah, if they just throw the take-home assignment at me right off the bat ... yeah, no thanks.

This all being said, yes, it is frustrating though to have to go through a bunch of these and get rejected with no feedback, or just ghosted, yeah.

Isn't that what "Twitch Turbo" is?

Yeah the (what I personally call it) "choose your own adventure" style approach to Clojure projects, where you don't use a framework like Rails, but just string together your own project from separate libraries, is really both a "pro" AND a "con".

It's great when you know what you're doing, and indeed, I have my own personal Leiningen templates to set up a Clojure project the way I like it and to save myself some time. Bigger project templates, like Luminus, I often find personally aggravating because I often feel like it just barfs a whole bunch of unnecessary and semi-complicated (in my opinion anyway) code in a new project even with the most minimal options chosen. But that's the power of the ecosystem ... you can create your own project templates to meet your own needs.

But a new developer getting their feet wet in this ecosystem? Yeah, it is hard. And even if they use an existing project template like Luminus to bootstrap their project ... well, the project template only helps generate the initial project. Ongoing maintenance for updating dependency versions and keeping a working integration of the libraries it initially set up for you (with respect to newer versions and any API/config changes, etc) ... well, those responsibilities are all on you! Kit (another newer successor to Luminus) _may_ provide some better alternatives here, but it'll still be limited with exactly how much it can help here. But I think it's still much too early to say one way or the other with Kit, so who knows.

(Also thanks for sharing your Ruby/Rails perspective on REPLs. A colleague of mine made some similar comments to me when we were discussing REPLs a while back, and I've not spent any time with Ruby so couldn't comment. It's interesting to hear! Most other REPLs I've used outside Clojure were not too useful as anything other than quick toys for trying short snippets outside of the context of a full project.)

That's an interesting point I'd not thought of. I guess I'm more looking at it through the lens of "interacting with and modifying a running system" which kinda gives you a debugger (ish), compiler and execution environment all rolled into one. It's kind of nice to work in this kind of "scratch pad"-like environment while you figure something out versus the more traditional edit-compile-run cycle. But I have definitely seen what you describe as well, so I think that aspect is worth considering too, for sure.

This is my experience exactly. I love the language and ecosystem in a lot of ways. I also believe that REPL-driven-development is a ridiculously productive way to work.

But I absolutely hate maintaining an old Clojure codebase (unless it's tiny).

The REPL helps a lot with discovering what the proper way is to call any random function you have in your code, but this is still really super annoying. I really hate to get into a dynamic-versus-static-typing debate, but I've long since come to the conclusion that -- all other things being equal (hah!) -- if I have to dig into a large and old project, I'd much rather have types by my side than not. Code will not ever be adequately documented or commented (and even if it _seems_ to be at first glance, you will always have nagging doubts about how up to date that info really is). This is where type definitions help to figure out the shape of the data that any piece of code is working with. People talk about adding spec/schema definitions but that doesn't solve all the problems with not having type definitions unless you add these spec/schema definitions _everywhere_ ... and let's face it, you just aren't going to do that in any Clojure project. So, best case scenario is you still have a large collection of functions in your project that are calling each other, etc that you are left having to deduce yourself what this random map or list actually contains.

Very cool!

Just tried this out for fun on my 486DX2 PC ( https://i.imgur.com/NOeR1Ad.jpg ). It boots, but obviously the minimal kernel only has included support for a small set of hardware, which does not include serial mouse, S3 805 VGA (works, but graphical artifacts), and 3C509 ISA network card. Will have to try out the provided toolchain and scripts to try and see if I can rebuild with better hardware support for my 486. Why bother, you ask? Why not, I say!

This is a really important point. I work with someone who has quite a bit of an ego. Definitely cares far too much about his personal brand, which has been built up over the years through open source projects. Any time you work on a project with this person you basically need to use all of his open source libraries if any of them are at all relevant for the project, regardless of if they are the best option for the task or not ... sometimes they are, sometimes they aren't.

By far, the best developers I've ever worked with are quite humble.

I'm not sure why you're contrasting Clojure and Java, but nowhere was I recommending using Java over Clojure (nor would I ever offer such a recommendation). Certainly there are much, much better choices for a statically typed language out there.

I think you've really summed it up well here. I have exactly the same concerns when looking at large Clojure codebases. It gets incredibly tiresome having to do this and even at the end of it, I'm still left with that nagging doubt "did I miss some detail somewhere?". Hopefully there's a unit test or three to help put my mind at ease but, at least at my work, that's really quite the pipe dream.

I can't say I've personally seen any evidence of "mass migrations" of this sort. However, I can personally say that after 5 years of working with Clojure and with several large Clojure projects under my belt now, I'm starting to realize that I'm losing confidence in using Clojure for large projects and the feeling of how _maintainable_ that project will be in 2-3 years or longer. I think Clojure hits a sweet spot (at least for _me_ personally) for small-to-medium sized projects though, and I don't hesitate to use it in those cases.

The thing I've _consistently_ seen with every large Clojure project I've been a part of is that as the project grows, it becomes harder to make sense of the types used across the project. On the last couple of these projects I've been on, Schema was used to annotate many types, but I've never found this to be quite enough and I still remain firmly convinced that gradual typing just doesn't work well enough generally. I think that with a _very_ highly disciplined team of experienced developers it could probably work well. But we don't all get the opportunity to work on such teams. What I've personally seen is developers are all too willing to either add a partial type spec/annotation (with probably some s/Any's lazily thrown in where there should most definitely _not_ be), or just flat out not adding any at all ("Why would I need it here? This is very simple code and it's obvious what is happening here!" ... sure, maybe it is to you now... what about in 6 months? Or what about to one of the other developers on the team?).

When discussions about static vs dynamic typing come up (which is almost always a fruitless argument in my experience), I've noticed that the dynamic typing proponents tend to get overly focused on the idea of "correctness". This has always disappointed me. Correctness is certainly an important benefit (though I think it tends to get exaggerated a bit much), however, to me the idea of documentation in the form of a type definition is _much_ more valuable over the longer term, especially so for large projects. Developers are usually quite lazy, especially when it comes to documentation, and often when looking at a piece of code in a large code base, the only documentation about the values being passed to a function is going to be the type definitions (aside from reading the code itself of course).

> Luminus looked good but seems to be shunned by the community.

Can I ask what left you with that impression? I've no idea if this is true or not as I don't participate much in the Clojure community, I'm just genuinely curious. I guess a bunch of people just use the lighter weight Compojure/Ring templates that really leave you with an extremely barebones web app to start with?

I used Luminus myself when starting out, but I feel that as you grow more comfortable with Clojure web dev, you'd _typically_ end up putting together your own Leiningen template more tailored to how you like to set things up (as I ended up doing). But even still, I don't think Luminus is by any means bad?

It's interesting to hear from someone else who also finds that Clojure/Lisp code can be difficult to read. I worked with Clojure professionally for 2 years and had started to think that I was the odd one out since everyone else I worked with was just gushing over the readability of the code. At times it could be easy to read, but very often I found it hard to follow and would have to spend more time then others deconstructing what was happening.

Which is not to say that I didn't like working with Clojure. I very much did. But it always seemed to be such a chore to read others code or code I hadn't seen in a few months or more. I remember on occasion showing some snippets of code to a co-worker and commenting that I thought there was too much "clever" code in there, that it was too dense and hard to follow. The co-worker didn't agree with me though, and I guess I just resigned myself to the idea that I was the odd one out here or something.

Ultimately, I think I ended up coming to the same conclusion as you. My way of thinking (and reading code apparently) just clicks so very much better with typed languages.

(I hope no one reads my post and treats this as some kind of attack on Clojure/Lisp and s-exps. It's not. I'm just noting that the style just doesn't jive with certain types of people. And I gave it plenty of time (2 years as noted above) before coming to that realization.)

It could be edited yes, but I'd assume once you change some Python code and recompile you'd lose your assembly tweaks. Not the end of the world I guess, but annoying if you're really trying to tweak things for maximum performance. All part of the trade off when using a high-level language for an extremely resource limited system such as the NES I suppose.

"Hackintosh" and "Laptop" don't go well together. Regardless of the type of laptop. A certain model HP laptop is a small exception, but it's not 100% perfect.

From my own personal experience running a Hackintosh on a desktop PC I built myself (using community recommended and tested compatible components), I can say that a desktop Hackintosh can be very stable.

However, with a laptop you will be making compromises. The exact compromises vary from laptop to laptop. Usually these will include Wifi, battery life and general power management stuff (hibernate, sleep, etc) and possibly more. For a Thinkpad specifically, I do know that you'll end up needing to use a separate Wifi adapter as the built in one will not work with OS X.

To be honest, since you seem dead-set on a Thinkpad (and I don't blame you, I love them myself) I don't know what to suggest, aside from "don't bother" which you probably won't find too helpful. I would just caution you, don't set your expectations too high, regardless of what you may read on tonymacx86 or wherever else. As runjake said, people have widely varying definitions of stable.