HN user

codr7

3,876 karma

codr7@protonmail.com

Posts79
Comments2,306
View on HN
github.com 1y ago

What it's like to tech lead at online casinos

codr7
2pts0
github.com 1y ago

Show HN: eli – Embedded Lisp Interpreter

codr7
45pts5
news.ycombinator.com 1y ago

Ask HN: Is This Good Bye?

codr7
10pts1
github.com 1y ago

Show HN: Lisp in C#

codr7
144pts67
github.com 4y ago

Show HN: Cl-extashy – Extensible hash tables in Common Lisp

codr7
1pts0
github.com 4y ago

Show HN: Snabl – a practical embedded Lisp in C++

codr7
2pts0
github.com 4y ago

Show HN: Snabl – a practical embedded Lisp in C++

codr7
3pts0
github.com 4y ago

Show HN: Snabl – a practical embedded Lisp in C++

codr7
1pts0
github.com 4y ago

Show HN: Snabl – a practical embedded Lisp in C++

codr7
2pts0
github.com 4y ago

Show HN: Snabl – a practical embedded Lisp in C++

codr7
3pts0
github.com 4y ago

Show HN: Snabl – a practical embedded Lisp in C++

codr7
6pts0
github.com 4y ago

Show HN: GFun – Lisp 4 Go

codr7
2pts4
github.com 4y ago

Show HN: GFun – Lisp 4 Go

codr7
8pts4
github.com 4y ago

Show HN: GFun – Lisp 4 Go

codr7
1pts0
github.com 4y ago

Show HN: gapl – a Go scripting language/toolkit

codr7
1pts0
github.com 4y ago

Show HN: gapl – a Go scripting language/toolkit

codr7
1pts0
github.com 4y ago

Show HN: gapl – a Go scripting language/toolkit

codr7
1pts0
github.com 4y ago

Show HN: gapl – a Go scripting language/toolkit

codr7
2pts0
github.com 4y ago

Show HN: Ampl – a C++ scripting language

codr7
3pts0
github.com 4y ago

Show HN: Snabl – a Common Lisp scripting language

codr7
2pts0
github.com 4y ago

Show HN: a custom Lisp in C

codr7
14pts2
github.com 4y ago

Show HN: a custom Lisp in C

codr7
4pts0
github.com 4y ago

Show HN: a custom Lisp in C

codr7
4pts0
github.com 4y ago

Show HN: A Custom Lisp in C

codr7
15pts3
github.com 4y ago

Show HN: a practical Lisp in C

codr7
5pts2
github.com 4y ago

Show HN: A hackable custom Lisp in C

codr7
5pts0
github.com 4y ago

Show HN: Build a Lisp in Swift

codr7
38pts3
github.com 4y ago

Show HN: Build a Custom Lisp in Swift

codr7
1pts0
github.com 4y ago

Show HN: Swifties – a custom language construction kit in Swift

codr7
1pts0
github.com 4y ago

Show HN: Build a Lisp in Swift

codr7
7pts1

I certainly learned this the hard way.

When I started writing code 40 years ago, I used to over estimate my understanding and abstraction skills a lot. As a result I created overly complicated and difficult to maintain/evolve solutions.

Turns out I need to see more examples of patterns before making good choices, which means becoming comfortable with seeing and tracking duplication over time.

God help us!

Far from everyone are cut out to be programmers, the technical barrier was a feature if anything.

There's a kind of mental discipline and ability to think long thoughts, to deal with uncertainty; that's just not for everyone.

What I see is mostly everyone and their gramps drooling at the idea of faking their way to fame and fortune. Which is never going to work, because everyone is regurgitating the same mindless crap.

PascalABC.net 5 months ago

Delphi had a good thing going for a while, a ton of potential.

But they pivoted themselves out of that real fast...

Are they still sending the entire stream as an element? Thereby making dealing with that xml a lot more painful than it needs to be.

Back in the days, I had to write my own parser, existing xml parsers couldn't handle the case well.

I don't think this is something that will happen inside of an existing language.

It needs to be a complete redesign where all parts pulls in the same direction.

Likewise, I never liked JS much, nor the frontend dev experience.

I started out with the Seaside framework, but I've done several variations on that theme in different languages along the way.

It goes something like this: A typed server side DOM with support for native callbacks, generates HTML and hooks up callbacks. Changes are submitted to the server similar to traditional HTML forms, but using JSON. Changes to the DOM generate JS that's returned from the submit.

One headache with this approach is that documents need to stick around or callbacks will fail, and you need to hit the same server to get the document.

It should be doable to put a serialized version of the DOM on the client and passing that to callbacks to be rebuilt on the server.

FORTH? Really!? 6 months ago

My own baby started out as a Forth dialect, but now sits somewhere between Logo and Common Lisp on the complexity scale. Forth is a good starting point imo, you don't waste any time on non essentials.

https://gitlab.com/codr7/shik

Nope.

Swift started out pretty nice but they've added too much Liquid Glass since then, the type system constraint solving madness and forcing actors down everyone's throat come to mind.

I don't touch it unless forced to these days.

Right, if you're nasty to people, they're less likely to be helpful in the future.

And helpful employees are priceless.

Goes around, comes around.

Bad news for all the a-holes out there who've built careers out of bullying others to do mediocre work.

The argument here, as far as I care to understand it rn, seems to be that micro services could actually live up to the promises if you follow ALL the rules religiously.

From personal experience, the problem is complexity. Which ends up costing money. At a certain scale, splitting off separate services may or may not make sense. But always building anything and everything as a set of black boxes that only communicate over network APIs, each potentially with their own database; is one of those ideas that sounds like fun until you've had a taste of the problems involved; especially if you have strong ACID requirements, or want to debug pieces in isolation.

I also taught myself to code; first on a C64, then A500, PC, Mac.

Then I studied robotics at university, which forced me to dig into several subjects I most likely would never have touched by free choice.

That foundation took me this far, we'll see what I'm doing once whatever this is has passed.

I'm not even sure I even want to work with software anymore.

No one gives a shit these days, which means experience is worthless and the chances of doing good few and far between.

Stop Slopware 7 months ago

I would say that's worse, because it lulls you into thinking it actually has a clue.

Following your "logic" there; 50% wrong would be even better, since it makes you question it even more.

The more you interact with that crap, the less clearly you think; it's the ultimate mind fuck.