Tisp: Time is space programming language | Hacker News Reader

Tisp: Time is space programming language

github.com

106 pointsdavidyapdy34 comments

Will be neat if it works. The problem with parallelization is that it's hard to get performance wins. There's a lot of benchmarking and you have to be careful to stay on the right side of Ahmadel's law.

Can the analysis be automated? I hope so. That would be cool.

Haskell itself is extremely amenable to this sort of thing but no one has figured out how to implement it AFAIK. It may be possible with profile-driven optimization to at-least guarantee adding a thread doesn't do more harm than good.

I wonder if anyone has written a language in Erlang. I imagine the prolog-like pattern matching could make lexing/parsing fairly easy and it would be straightforward to add concurrency wherever you needed. The only downside I can see is that maybe interpreting a language would be too cpu intensive for Erlang

Nice piece of work, but:

> This is an immature concept

I believe the author meant an immature instance of an old concept, certainly.

Just spend an afternoon looking into the literature about parallel programming languages, data flow programming languages, or flow-based programming languages, and you will realize that this is certainly not an immature concept. Research in that spaces has been going on since at least since the early 70s.

Well I'm glad you nitpicked what he wrote even though you knew what he meant. I'm sure he appreciates it.

He's cited several older languages, so it's pretty obvious that he's aware of some of the historical happenings related to parallelism.

Edit: he or she, or whatever

What he did with the syntax suggests that being aware of something doesn't imply understanding much of it.

It's a he

With hindsight he's a he :)

What is time is space?

Edit: found the explanation in here: https://raviqqe.github.io/tisp/

Cool concept, are there other languages that do this concurrency by default thing?

I have a language called Winter that has experimental support for automatic parallelisation: http://www.forwardscattering.org/post/22

labview. it's really great. when i recently did a multithreaded application in python, it felt ancient and like a step or two backwards.

"Impure function calls in pure functions are detected and raise errors at runtime."

Is there value in having a pure/impure distinction when all pure functions end up needing a try/catch around them?

Yes - you can run unit tests? Still not the best, and compile-time would be better, but I'm not sure that's achievable in golang.

Can you elaborate a bit on what you mean?

It seems like this distinction could be done at compile time instead of at runtime.

Ah okay, makes sense.

I really like the "parallel" by default paradigm, or perhaps rather, I think it has great potential. When you consider any hardware design (Verilog, Chisel, etc.) the default is to execute in parallel, and sequential is explicit i.e. by instantiating a flip flop or other memory element. If you write in Verilog, you can arbitrarily reorder your lines of code and the resulting hardware is exactly the same (modulo anything you did with always blocks which can be entirely restricted to your sequential elements if you wish).

https://en.wikipedia.org/wiki/Dataflow

> Data-flow hardware (see Dataflow architecture) is an alternative to the classic Von Neumann architecture. The most obvious example of data-flow programming is the subset known as reactive programming with spreadsheets. As a user enters new values, they are instantly transmitted to the next logical "actor" or formula for calculation.

Nobody (yet) has been able to get dataflow languages fast enough to beat conventional ones.

labview is quite fast.

Slight off-topic, but why people are using Google groups? That site feels so unusable, yet seems to attract all the leet (Tisp author suggests discussing in the group he created there).

I have a gmail account that is just for Google Groups. Sign in, join group, sign out. Works like any normal mailing list after that, but with better search. Read messages in Thunderbird. Keeps my list subscriptions out of my main email account as well.

Two main reasons why people use it: 1, Google uses it (e.g., Go mailing lists). 2, historic reasons: it's a spiritual successor of sorts to Usenet. Google bought Dejanews in 2001, then merged it into Google Groups and gradually killed all the Usenet parts of the service.

Aside from that, it's main competitor is GNU Mailman, which is self-hosted and doesn't have many real benefits for end users (other than not requiring a Google account).

Hosted, free, indexed on Google search, simple and reliable admin, email and web forum style usage.

I'm not what could be better without paying or self hosting, though I do wish we could have built in formatting like Github and an API for the messages.

Something like reddit seems way more useable.?

Reddits don't work via email, though I envy the tree approach to discussions

FYI, you can have tree-threaded conversations in email too. Thunderbird has pretty good support for it, which is why I use it for mailing lists.

The only reason more people don't know about this is that support for it has always been poor at best in Outlook, which is what most of the world uses as their email client.

In Thunderbird the option is View > Sort By > Threaded, which you need to set per folder (it's off by default). I set up filters so I have one folder per mailing list.

This is not the same as Outlook's group-by-conversation feature, which is based on subject lines. It is full tree-threading based on the in-reply-to header, same as Usenet.

Is email still... big?

I presume it's good for long timeframes, where you can go months without a notification.

This language is coded in Go. Just recently I was wondering if there were any Go-coded languages out there which were inspired by Haskell, Clojure, and OCaml. I have read that the Go compiler includes design choices from Plan 9 which make it both fast and simple to manage. I wonder if inheriting this supposed advantage will help Tisp in the long run.

I'm working on a shell scripting language that, like Tisp, is rooted in functional and concurrency paradigms while still offering some degree of backwards compatibility with traditional shells like Bash.

It's very immature at the moment but the repo is below if anyone else is curious:

https://github.com/lmorg/murex

I'm not suggesting my level of coding is comparable with the others mentioned though. Murex was created to scratch an itch rather than delusions of thinking I could write a powerful next gen programming language. I intend murex to be more of a REPL shell than something one would use to write scalable applications.

Your approach to murex "to scratch an itch" reminds me of Larry Wall's motivation to create Perl. :) Did you draw any inspiration from Perl? What about PowerShell? That's Microsoft's now cross-platform shell language - it also enables one to accomplish a lot with simple one liners.

Thanks for sharing! I'm using NixOS right now & perhaps it would benefit from a murex package.

Btw your github looks awesome! DHCP as a FUSE filesystem?? Woah.

There was Oden[0], which is supposed to be a functional programming language inspired by/and written in Go. That, until a few months ago when the author stepped down.

[0] https://github.com/oden-lang/oden

I checked out the homepage & read the "Taking a Step Back from Oden" post. This project certainly had some high ambitions. Thanks for sharing.

Not long ago another attempt at flow-based programming was on HN. Whereas Tisp is implemented in Go & Lisp/ML-influenced, Fractalide is Rust & leverages Nix: https://news.ycombinator.com/item?id=13138271 https://github.com/fractalide

I like the idea of wrapping forms in (seq ...) explicitly. This makes the program read more closely to the declaration of a state machine, with smaller sections that represent state transitions (and are, most likely, expected to be atomic).

So, this is basically functional reactive programming?

Possibly minus the "functional", I haven't looked that closely at it. Haskell has some libraries that attempt to implement the concept, though.

> - Purely functional programming - Impure function calls in pure functions are detected and raise errors at runtime.

Bzzz, wrong answer. This is too naive to be workable. It implies you need to drop out of your language in order to _build_ those functional components.

Reply on news.ycombinator.com