Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cell Lang: Why yet another programming language?

cell-lang.net

Post reply on HN
Print view View original

11–20 of 126 posts

Re: Cell Lang: Why yet another programming language?

#11

Post by Scandiravian »

kortex wrote: post #6

It's frustrating that innovators are constantly having to justify "why yet another". Folks should just be able to freely innovate without fear of getting spammed with xkcd#927. You wanna make yet another programming language, compiler, JSON-alternative, container format, or trivial FTP+SVN killer, go for it! This is how we innovate.

Agreed! Even if the new thing doesn't reach mainstream adoption it might still cause change in the mainstream choices - like how redux was inspired by Elm

Secondly I think it's sad that someone building something will be asked to justify their decision in terms of economics. If it makes that person excited and happy to build a thing then I don't think any further justification is needed

Re: Cell Lang: Why yet another programming language?

#12

Post by pca006132 »

verdagon wrote: 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…

Ｉ 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 or do other actions. If the mutable states are not shared and execution can be recorded, we can just restart the library after abort and resume to the previous state.

Re: Cell Lang: Why yet another programming language?

#14

Post by jolux »

This looks very interesting. I'm curious if the author has looked at Erlang/Elixir — my first reaction on reading this is that it sounds similar to the actor model and the way that Erlang handles state and state updates: as messages to autonomous processes that are modeled as a continuous fold over the message stream.

Re: Cell Lang: Why yet another programming language?

#15

Post by dgb23 »

I think robust information software (AKA "CRUD" apps, data visualization and interaction etc.) should definitely be built with higher level paradigms, DSLs or a language that provides such capabilities out of the box for these reasons:

- principle of least power

- can often be talked and reasoned about more easily

- lends itself to visualization

- can be tested more easily and uniformly

- eliminates certain classes of accidental complexity

So yes it makes sense to use...

- relational algebra for data manipulation where feasible, functional programming for the rest

- (data driven / functional) state machines for control

...like the article is suggesting. I also kind of like the idea about I/O but I'm not 100% sure there, because I never played with such a system. Reactive programming is powerful too to manage data flow and again hides away plumbing and side-effects.

In a sense this is kind of already how many are programming in modern FP languages like Clojure (via libraries).

What we possibly lose with these approaches is performance, except the runtime/macros are fine tuned to make automatic optimizations, so some of that can be gained back in the long term. But I generally agree that there is tons of leverage in programming these things at a higher level.

Re: Cell Lang: Why yet another programming language?

#16

Post by verdagon »

Scandiravian wrote: post #11
kortex wrote: post #6

It's frustrating that innovators are constantly having to justify "why yet another". Folks should just be able to freely innovate without fear of getting spammed with xkcd#927. You wanna make yet another programming language, compiler, JSON-alternative, container format, or trivial FTP+SVN killer, go for it! This is how we innovate.

Agreed! Even if the new thing doesn't reach mainstream adoption it might still cause change in the mainstream choices - like how redux was inspired by Elm Secondly I think it's sad that someone building something will be asked to justify their decision in terms of economics. If it makes that person excited and happy to build a thing then I don't think any further justification is needed

In my experience, people believe that programming languages are a solved space, and we should stick with what we have. It's an unfortunate view.

Languages are actually very polarized today. I think there's a lot of room for a mainstream language that could be safe, fast, and most importantly, easy. Today's languages are generally two out of three.

Luckily, a lot of languages are exploring that space!

* Vale is blending generational references with regions, to have memory-safe single ownership without garbage collection or a borrow checker. [0]

* Cone is adding a borrow checker on top of GC, RC, single ownership, and even custom user allocators. [1]

* Lobster found a way to add borrow-checker-like static analysis to reference counting. [2]

* HVM is using borrowing and cloning under the hood to make pure functional programming ridiculously fast. [3]

* Ante is using lifetime inference and algebraic effects to make programs faster and more flexible. [4]

* D is adding a borrow checker! [5]

[0] https://vale.dev/

[1] https://cone.jondgoodwin.com/

[2] https://www.strlen.com/lobster/

[3] https://github.com/Kindelia/HVM

[4] https://antelang.org/

[5] https://dlang.org/blog/2022/06/21/dip1000-memory-safety-in-a...

Re: Cell Lang: Why yet another programming language?

#18

Post by goodpoint »

kortex wrote: post #6

It's frustrating that innovators are constantly having to justify "why yet another". Folks should just be able to freely innovate without fear of getting spammed with xkcd#927. You wanna make yet another programming language, compiler, JSON-alternative, container format, or trivial FTP+SVN killer, go for it! This is how we innovate.

> innovators are constantly having to justify ... This is how we innovate

Quite the opposite.

Having to explain the benefits of an idea do not thwart innovation - if anything it promotes it.

The software industry is littered with novelties that have little innovative value other than being the new shiny thing that people want to put on their CV.

Churn is at a historical high.

Providing solid reasons for adopting new technology is a breath of fresh air.

Re: Cell Lang: Why yet another programming language?

#19

Post by dlojudice »

dgb23 wrote: post #15

I think robust information software (AKA "CRUD" apps, data visualization and interaction etc.) should definitely be built with higher level paradigms, DSLs or a language that provides such capabilities out of the box for these reasons: - principle of least power - can often be talked and reasoned about more easily - lends itself to visualization - can be tested more easily and uniformly - eliminates certain classes o…

> higher level paradigms, DSLs or a language that provides such capabilities out of the box for these reasons

Based on exactly this arguments that we created HerbsJS [1], a domain-first library to build microservices. While the essential complexity can't be removed [2], we should put effort to remove the accidental complexity as much as possible.

BTW, great to see this kind of discussion here and congratulations to the team responsible for Cell Lang.

[1] https://herbsjs.org/

[2] https://en.wikipedia.org/wiki/No_Silver_Bullet

Re: Cell Lang: Why yet another programming language?

#20

Post by culturedsystems »

kortex wrote: post #6

It's frustrating that innovators are constantly having to justify "why yet another". Folks should just be able to freely innovate without fear of getting spammed with xkcd#927. You wanna make yet another programming language, compiler, JSON-alternative, container format, or trivial FTP+SVN killer, go for it! This is how we innovate.

When people write "why yet another", they usually mean "why this one specifically". And that's the case here, where the author lists what they think are the weaknesses of the state of the art, and explains why they think their innovations help with these problems. Innovation on its own isn't particularly interesting - I want to know why the author is innovating.
Post reply on HN