hurril

Joined 5 years ago

Karma
555
Submissions
291
Member since
Dec 11
# Functional toy language https://github.com/pandemonium/lukas-rs
View on Hacker News

Recent submissions

Comment · 22 days ago
I love this thread. We spent so much time in mIRC, about warez, weirdness but obviously tons of programming. Fun was had :)
Comment · 22 days ago
Add mIRC 4.51 to that list. Fit a 1.44M diskette. Launched fully before you let go of the mouse button, on an old POS 486.
Comment · 23 days ago
I have talked to them, it is a dev shop, this is what they said.

You can Linux all you want, I prefer Mac and I have done Linux extensively.

Comment · 23 days ago
I just hate the fact that I am to start a new contract at a Windows shop because IT hates Mac. Most people there would want a Mac given the choice, among the other developers, there is also a Linux crew. But no! It dept says no, so they hold the rest of us hostage.

Why are you like this?

Comment · 1 month ago
No it is not solved. Grid-scale batteries are absolutely not being mass-produced today. Let's stick to the truth here.

I would LOVE for this to be the case, however. Adding this again so that I am not lumped together with the coal thumpers.

What exists, TO BE BUILT that is, is battery farms, sure, but they are nowhere nere big enough. They are nowhere nere close enough to compensate the factor applied to wind farm energy generation. But let's hope good progress can be made in the accumulation aspect of intermittent energy production.

Comment · 1 month ago
What? Absolutely not, I love capitalism. The problem is that it is suspended when it comes to the wind farms, they are pretty much always heavily subsidized and on a socialized loss scheme at that.

And no, I have no problem with renewables either.

If your conclusion from reading what you said is this, then you did not read because I said the exact opposite.

Comment · 1 month ago
I am a non-hater of renewables. I add this because in plenty of _your_ circles, you are either all in on renewables or you are a coal thumper, basically. I am neither. We need to add nuance by complicating this conversation.

The main problem of renewables is that it is intermittent and that fact remains to be solved. I want this solved or at least improved because it is the bottleneck. In fact, it is such a bottleneck that its energy generation factor is noted as 1:10, i.e.: a power plant rated at 100MW, registers as 10MW in comparison to nuclear and hydro (and obviously coal and gas.) So this means that to add a 1MW worth of energy generation to the grid, 10MW must be built.

Another problem that hits wind farms is that when there's wind blowing somewhere, it tends to blow everywhere, or some large area. So suddenly there is too much energy want to flow in to the grid which hits the core of the problem with grids at this point because energy that is inserted into it, must be extracted to the exact same magnitude at the same time. So a 100GW demand must be met by 100.0GW production. Now if 110GW is produced, something _MUST_ consume it, so there are two choices:

1. make someone consume it, i.e., sell it to them. They have to buy it so the price will drop until there are enough buyers and this does not stop at 0, prices will go in to the negative. So the market will pay you to use electricity. The market. Or:

2. shut off the power plants until we are back at 100GW (or whatever can be met by consumption.)

3. there is also a catastrophic third option. If you have a situation where too much energy (read power if you want to) is inserted into the grid, then its frequency will rise, this damages the infrastructure and connected consumers, so they will get disconnected. Read large and broad power outages. These situations are also non-trivial to recover from. I.e.: to "restart the grid" afterwards. See what happened in Spain last(?) year.

How do you run a power plant in a market that demands payment to accept the energy you want to sell? You cannot. So this is the windfarm paradox, feel free to compare to Russel's paradox. It goes something like this:

A windfarm makes money whenever the wind blows because only then does it have energy to sell.

A windfarm cannot make money whenefer the wind blows because then the market price goes to zero.

So a windfarm makes money when the wind blows and does not blow at the same time.

To solve this problem, energy consumption must be made capable of also being intermittent. Either run "factories" intermittently, which might very well be part of the solution. And/ or, have huge accumulation capacity in the grid that can swallow the over generation.

TLDR: renewables is the easy answer but very hard thing to do. The hard answer is the one I have given, together with getting more nuclear going which is difficult and expensive. But.. what can we do?

Comment · 1 month ago
Easiest. If that is the easiest way you see I am afraid to ask what the harder alternatives would be.
Comment · 2 months ago
That is just not the case. I have worked, full time, as a functional programmer coming up to 15 years, in different langauges. Actual functional programming and not merely doing web programming with React.

"[...] pure functional programming whilst still functioning."

I mean, what is this?

When I read what you are saying here, you are saying that an "advanced codebase", whatever that means, using functional programming leads to centralized state and distributed components. And you know this because the codebase you are thinking about has this software architecture.

I have been in such codebases too, they tend to be frontend and maybe that is just the way you have to do it, maybe not. But this is not a property inherent to functional programming. Solving problems with a component or object concept as a central abstraction for "a thing" is the OOP way. I know this because this is how I spent the first half of my career. You think you need a _substantive_ onto which you perform verbs. Nothing wrong with this though, I am not picking a fight with OOP.

I can offer what I refer to when I talk about FP so that we can at least have a real thing to disagree over :)

1. model the domain and interactions with it with strong types such that neither interactions nor state can represent values outside of the domain.

2. parse, don't validate

3. Use modules, stateless collections of declarations, to organize stateless functions. No this. No self.

4. No magic code. I.e.: no null checks, no magic number checks, no arbitrary logic in four places that together make up the fact that prices can have taxes. Abstract it and "store" these runtime decisions using typed values, use functions that accept these typed values to force use of the aforementioned types.

5. Control the side effects. This does not mean that you have to use Haskell or monads or anything like that. Just that managing it is a good thing.

6. #5 implies keeping track of state. I.e.: no, you may not just willy-nilly read it from the persistent store, cache or file.

Comment · 2 months ago
Component is not a term out of the FP schoolbook. I am sorry to be making what smells like a true scottsman here, but you seem to be describing a React codebase since they call themselves functional with that Redux stuff, you think this is functional programming. A graph of "components" all talking amongst each other. Functional. Programming. Come one, man :)

What you are describing is OOP. Passing messages between identities over calling pure functions with values.

Comment · 3 months ago
I also write with fountain pens these days. Do you have a favorite model?
Comment · 3 months ago
All four of these are awesome tips, thank you!
Comment · 3 months ago
Do you have anything in particular in mind here? Long time macOS user but I like a good pro tip :)
Comment · 3 months ago
Right and C has a special place in my heart. I have never coded C in anger, but the weird thing about coding in Java is how low level all the implementations are. I've had this debate/ conversation with people over the years and I realize that if I am the only one at a certain position, then I am wrong and not everyone else.

But I claim that Rust is actually a high level language. Higher level than Java. My argument is that in Rust (, F# and Scala) you can encode in structure, what has to be operational code in Java.

So in the stronger languages you can reason about larger swaths about domain concepts easily, whereas in Java you have to trust the test panel on faith and wade through deep sections of "magic code" (compare with magic numbers. Why is there a 427/ these 7 lines of logic here? What does it do?)

Comment · 3 months ago
I am not. I am saying that had I been a good little Java/ C# developer, then I would never have learned Rust and all of the things that come with that.

Scala is not doing great, probably because they took too long to get 3 finished and good.

Yes. Companies are going back to Java because this is what all the convervative guys and girls want to use. That fact is what I am criticizing. You want fast horses, you don't want nice things.

So now you have Maven, semi-typed code intermingled with container logic because you cannot abstract over anything, you have millions of lines of impenetrable tests. Just like we all did in 2006. You all love this because learning things is not your forte :) That other stuff is for academics and niche.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton