Did you forget to include `middle-name`?
There's no way to tell.
1,365 karma · joined August 3, 2015
I'm a husband and a father of two. I've been working in Scala for over a decade, and I'm part of the founding team at Paqle.
I work on a full stack programming language called Firefly and I organize a functional programming meetup in Copenhagen:
https://www.meetup.com/moedegruppefunktionellekoebenhavnere/
It's once a month - swing by if you'd like to meet up!
meet.hn/city/55.6867243,12.5700724/Copenhagen
There's no way to tell.
- object capabilities
- implicit async/await
- immutable collections
It's small and (hopefully) fun, and quite usable already. If you try it out, please share your thoughts!
> When they did this, they found that every single piece of software they tested except for SQLite in one particular mode had at least one bug. This isn't a knock on the developers of this software or the software -- the programmers who work on things like Leveldb, LBDM, etc., know more about filesystems than the vast majority programmers and the software has more rigorous tests than most software. But they still can't use files safely every time! A natural follow-up to this is the question: why the file API so hard to use that even experts make mistakes?
In Firefly, you can specify dependencies at the top of the file:
When your project grows, you can move the dependencies to a single shared project file.
Instead the null propagates somewhere else where you assume non-null, and you get the panic there.
That's bad error reporting, and it only happens because Go lacks a proper nullable/option type.
If Canvas contains NodeSystem, then Canvas must be a capability type itself.
Yes, you can store the system value (or indeed any other object capability) in a list.
If a function takes in a List[NodeSystem] parameter, then the function can perform side effects through the methods on NodeSystem.
However, if a function takes in a List[T] where T is a type parameter, then that is not enough to perform side effects, even if that function is later called with a List[NodeSystem] argument. There is no way for the function to access the methods of the concrete type of T.
Hence, you can tell whether or not a function may have side effects from the function signature alone.
We're working on a language with some of these ideas:
Object capabilities, async calls as easy as sync calls, modular monoliths, and (eventually) unified logging.
None of the relational language features though.
Feedback appreciated!
Why spend your life doing something a computer could do for you?
The goal of programming is not to write code (however much I enjoy that part), it is to solve problems.
I don't think copilot et al is anywhere close yet though. They are occasionally useful when working with popular APIs you use very rarely, or when you need to write some very repetitive code. Other than that, I feel like it's mostly a monkey typing plausible but incorrect code on my screen everywhere I go.
That's lazy design, and it doesn't work.
It does break with standard shortcuts. And worse, there's absolutely no consistency between terminal applications on which shortcuts to use. It's a mess, and complaints are warrented.
No human ingests that many tokens of speech; individually we learn from far fewer tokens.
New features often interact poorly with some of the existing features, as those features weren't designed with the new feature in mind.
It's seductive, but there's a steep cost. You bring in a bunch of new notation, which you have to learn and teach and remember. You have to consider all the interactions that happen when you mix notations. You have to implement all the tooling.
Usually what happens is you don't quite remember what things mean after a while, and you have to study it again. You didn't consider all the interactions, so it isn't that well behaved. And you never got around to implement quality tooling - and there's no obvious place to plug that tooling in, either. And then it turns out that the notation wasn't quite right for implementing the changing requirements of the business.
But then, all languages since Objective-C seem to agree that namespacing is a good idea. There's no debate there. Even JavaScript has modules now. So I can't help but wonder what makes web components unique in this regard.
In my opinion, fundamental problems like these really ought to be addressed before things become part of the web platform.
This is exceedingly complex, error prone (because you might miss parts of the state that should change) and often slow (because you tend to overcorrect).
list.map (lambda f => readFile! f) winIt does seem a bit pricey though. For $69/month (Scale), I could rent a dedicated server with 8 dedicated CPUs, twice the RAM and 20x the storage (and that's physically attached NVMe in raid 1), and have money to spare: https://www.hetzner.com/dedicated-rootserver/matrix-ax/