81–90 of 126 posts
Earlier quoted context omitted.
Lisp does it too ( https://lisp-lang.org/ ) - I think it's a reasonably familiar convention
I'm not talking about domain names. I'm talking about people referring to the language itself as, for example, Rustlang.
> Why yet another programming language? 'Because I wanted to' is a sufficient reason. Create all the programming languages you want and share it with the world!
I know it's a total pipe dream, but this is what makes me most sad about lisp never being taken seriously. It could have been common practice to create and pull in new language constructs like what this is doing.
Go is pretty similar to a lovechild of C and Scheme, for instance, Python and Ruby have many handy pragmatisms from Lisp style development, and so on.
Don’t worry yourself about when the next programming language will be written. Worry instead about when the last one will be written.
> and how tedious and time consuming it often is to implement even trivial things like sending data from the client to the server and vice-versa. Let's be clear here, the complications there are as follows: 1. Authentication and permissions in regard to the end user who is making the change or fetching the data. (E.g. internal web app, the AWS hosted database has no knowledge of my corporate AD accounts) 2. Authentic…
I think a more charitable interpretation would be that they're highlighting how much work has gone into that area (web server frameworks come to mind), compared to how little work they've seen on cleaner techniques and language assistance for managing local state. That's how I read it at least, reasonable interpretations may differ.
I do not see the problem they are trying to solve. Doing I/O is hard, not because sending bytes on a wire is hard but because of everything that can go wrong. It is the "everything that can go wrong" part that is hard.
They are going to solve the problem of state with "algebraic data types". That is not new. I am trying to think of a language at a higher level than machine code that does not use algebraic data types. ("Algebraic data types" are not an invention, they are a description)
I cannot see anything new in this. I fear it is another example of making easy things easier and pretend the hard things do not matter.
There have been huge strides in the development of computer languages in recent years. Rust, Go, Swift, Dart.... All of them with slightly different use cases and solving slightly different problems in slightly different ways. But the author knows of Closure... Yes, but.
"One can easily reconstruct the exact state of a Cell program at any point in time." Really? I spend my entire professional life doing exactly that, whatever the system I work in.
This is engineering with machines. State is part of the nature of those machines. It is very well understood and is not a problem (handling state) that we are struggling to solve.
When I clicked on the page I wanted to see an example and know if the language is meant for someone like me I saw a huge page and clicked on links to find more pages just as big. I figure it's not for me because I love mini examples and low level and saw nothing like that. So I wanted to say, you're probably not targeting me but make sure whoever you are targeting will know it's for them based on your site. No matter…
It has a link labelled "Introductory example" at the top left of the linked page. ...in the section called "Start Here". I'm not sure how much easier they could make it to see some example code with detailed explanations.
Earlier quoted context omitted.
I think a more charitable interpretation would be that they're highlighting how much work has gone into that area (web server frameworks come to mind), compared to how little work they've seen on cleaner techniques and language assistance for managing local state. That's how I read it at least, reasonable interpretations may differ.
But I cannot agree. I am very down on this. I think this a colossal waste of time. I do not see the problem they are trying to solve. Doing I/O is hard, not because sending bytes on a wire is hard but because of everything that can go wrong. It is the "everything that can go wrong" part that is hard. They are going to solve the problem of state with "algebraic data types". That is not new. I am trying to think of a l…
They could have phrased their article better, sure. But lets not cherry-pick one sentence that's barely relevant to the rest of the article and use it to fuel our anger that they aren't solving Our Favorite Problem. Instead, let's focus on what the author is really trying to get across: that a language can help manage the complexity that can come from mutable state.
If you read the article with a more charitable lens, you'll see that the author is saying a lot that could be new to many readers: a language can combine relational data with functional transformations, a language can expose these patterns to enable more solid architecture, a language might support first-class reactive programming, and a language could (if high level enough) offer replaying and snapshots.
That's honestly fascinating, and I would love to see what kind of ecosystem can grow around a language offering such features.
[0] https://themindcollection.com/steelmanning-how-to-discover-t...
> The state of the application can be partitioned in separate components (called automata) that do not share any mutable state and can be safely updated concurrently. This is the right direction! Pure computations on (somewhat) centralized data has proven to be very resilient to bugs. It's kind of like how React organizes its programs. I like how Cell is tackling this problem at the language level. A language's progr…
In industrial design this is called an affordance. The product is designed to encourage correct usage and make incorrect usage difficult. I would like it if more language designers will carefully consider their language’s features like this. The Elm language is a good example.
So basically an actor system with relations between actors, reactivity and automatic persistence. Very interesting concept! Although I do wonder if this couldn't be implemented as a library for an existing language. Doesn't seem like it is actively developed though, the compiler repo hasn't seen updates since November and the runtime repo since 2018.
> Although I do wonder if this couldn't be implemented as a library for an existing language. It definitely could. So could Elm, which — nonetheless — is an interesting and useful language (bordering on DSL).
Also there is an Elm-Architecture clone in almost every language. You could also emulate it in React (probably using top level state, prop drilling and following the same patterns, typescript would help)
I've always been intrigued by the idea of a language that enforces a separation of queries and command. Functions (queries) return values and have no side-effects, where procedures (commands) that can have side-effects and don't return a value.
The pure query inside a command might still add cost to the command though.