Live data from Hacker News

Cell Lang: Why yet another programming language?

cell-lang.net

101–110 of 126 posts

Re: Cell Lang: Why yet another programming language?

#101

I'm still reading this, but I have this nagging feeling about how great it would be to team up. My programming language chops are not cutting edge, but im bleeding edge in real-time distributed systems. I've built https://www.adama-platform.com/ and im playing with the language to map idioms that work to a language which can enforce good discipline. Now, im highly unfocused as im an retired monk code machine (i just…

I'm also working in the languages space, I would love to hear your feedback for them and ideas in this realm in general, especially since they don't seem to be that active anymore. My email is my username @gmail.com, feel free to reach out!

Re: Cell Lang: Why yet another programming language?

#102

This is really great, because it touches on the concepts of hardware design. I've thought a lot about this myself, and I'm honestly surprised to see someone else discussing this. Maybe I'm way out of my depth here, but the idea of stateful programming doesn't actually fall under the paradigm of sequential programming (think single threaded programming.) We all like sequential programming for the same reasons we like…

This is interesting. I've been trying to model UI flows in a "CPU-like" manner, as incremental state transformations that are committed at most once per frame. That's the basis of some UI frameworks like Jetpack Compose, which bundle the incremental state in a global snapshot, sidestepping most of the pitfalls of mutable state by controlling when mutations are applied. What's neat about this paradigm is that you can write fairly naive code that reads and mutates state with abandon, and the snapshot mechanism lets the code just work without modeling the whole app as a state machine.

Re: Cell Lang: Why yet another programming language?

#103
post #8

> 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…

I think this may also be a good way to separate libraries from application code, by considering the library as another actor instead of a direct function call. We are allowed to panic within the same abstraction layer (application or in a library), but panic should not cause another application using it to abort, there should be a way to let the application recover from it and decide whether to cancel the operation o…

This description makes me immediately think of Erlang (and Elixir).

Re: Cell Lang: Why yet another programming language?

#104
I'm going to leave some simple directions for creating and running Cell-o World. The website is verbose and it doesn't spell out blow-by-blow how to do this in "getting-started":

1. Download the Cell compiler from the website and ensure you have a recent enough version of Java installed:

2. I made a copy of one of the example project directories, /send-msgs/, called /hello-world/.

3. Change directory to /hello-world/.

4. Command to compile: >java -jar ../../bin/cellc-java.jar project.txt ../hello-world/

5. Command to run: >java Generated.java init-state.txt msg-list.txt output.txt

Now all you have to do is read the docs, get hands-on, experiment, and you can get a feel for how Cell works.

Re: Cell Lang: Why yet another programming language?

#105

Earlier quoted context omitted.

Languages that rely on the user creating their own language constructs suffer from a balkanization of the language - each team creates their own language, and cannot share code. This is why D does not have a macro preprocessor.

I hear this concern a lot, but I’ve never actually seen it happen any more than it does in languages without macros. https://news.ycombinator.com/item?id=31520381

I've seen it enough. Case in point, back in the 80's a friend of mine worked at Microsoft. A manager came to him with a lament that there was a program that compiled to 50K, written entirely in macro assembler. It had a bug in it. He had assigned it to multiple programmers, each of whom failed after trying to fix it for several weeks.

The problem was the author had invented his own language with the macros, left it completely undocumented, and nobody was able to make heads or tails of it.

My friend said, no problem, he'd give it a try. 2 hours later he had fixed it and checked it in.

Astonished, the manager asked him how he'd figured it out. My friend said he didn't. He ran it through the disassembler I'd written https://www.digitalmars.com/ctg/obj2asm.html (which is why he related the story to me) because it turned object code into asm source code. Found the bug, fixed it, and checked in the new source code.

Not only that, I discovered I could not read my own macros a few years after I'd written the code.

I've seen similar terrible examples that make use of expression templates in C++. They were all the rage for a couple of years. Fortunately for C++ programmers, expression templates are so miserably slow to compile that a blessed damper was put on the exploitation of this discovery.

Feel free to disagree with my assessment of this. You'll have plenty of company. But use macros enough and eventually you'll agree with me :-)

Re: Cell Lang: Why yet another programming language?

#106
post #85

Earlier quoted context omitted.

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…

> 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. Wow, really? If handling state is not a problem, then what problems do we actually have?

Mostly, trust in some form. That is what we know about some one else's state

Re: Cell Lang: Why yet another programming language?

#107
post #71

> 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.

> compared to how little work they've seen on cleaner techniques and language assistance for managing local state.

Literally every new web framework is some new take on how to manage local state.

You could spend an entire year learning about different state management solutions. From systems that keep backend and front end state in sync, to the entire redux/mobx family, to the stuff that Svelte does.

We are a long ways away from the bad old days of a global "state.c(pp)" file.

Re: Cell Lang: Why yet another programming language?

#108

Earlier quoted context omitted.

I suppose you could add a few to this list: Koka has formalised side-effects, and thanks to that can do in-place mutation after static analysis, similar to HVM. It also uses static analysis to manage memory with elided reference counting. Lastly, koka has managed to utilise static typing with dynamic binding, contrast with cell-lang which avoids dynamic binding (which has it's use cases). https://koka-lang.github.io/…

Wow, I've never heard of most of these languages, and I consider myself a language expert! How did you learn of these?

Mainly reading threads here :) I make a stab at looking at the top headlines. There's a pattern in a headline eg. Mentions of GC, datalog and so on which I flag.

The exceptions are Composita and Maude. Composita is off the back of Oberon, which is one of the smaller language-based OSes. Maude I found on a keyword search around formal verification- I'm looking to build a new language so interesting stuff keeps coming up when you go down the rabbit holes ;)

Re: Cell Lang: Why yet another programming language?

#109

Earlier quoted context omitted.

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.

Languages that rely on the user creating their own language constructs suffer from a balkanization of the language - each team creates their own language, and cannot share code. This is why D does not have a macro preprocessor.

On the other hand, Rust's macros enable one to use future language features without ever touching the compiler.

Re: Cell Lang: Why yet another programming language?

#110

Earlier quoted context omitted.

I hear this concern a lot, but I’ve never actually seen it happen any more than it does in languages without macros. https://news.ycombinator.com/item?id=31520381

I've seen it enough. Case in point, back in the 80's a friend of mine worked at Microsoft. A manager came to him with a lament that there was a program that compiled to 50K, written entirely in macro assembler. It had a bug in it. He had assigned it to multiple programmers, each of whom failed after trying to fix it for several weeks. The problem was the author had invented his own language with the macros, left it c…

> But use macros enough and eventually you'll agree with me :-)

I spent a long time writing Clojure professionally, and macros were used extremely rarely. People definitely didn’t create their own languages.

I guess it may also be a function of the other abstraction facilities in the language, the culture around the language, etc.

Post reply on HN