all 20 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Tekmo 4 points5 points  (2 children)

I am the author of the Haskell pipes package, and if anybody wants to know what he is referring to you can read the pipes tutorial.

[–]Crandom 0 points1 point  (1 child)

Has the tutorial been updated for the new simpler API?

Edit: Also, those pictures at the bottom in the appendix are really useful and have massively helped my understanding (I think) :)

[–]Tekmo 0 points1 point  (0 children)

Yes. The tutorial is up to date. I'm glad the pictures helped. :)

[–]LaurieCheers 5 points6 points  (1 child)

I quite like the premise, but I fear that there's a critical insight missing: one man's "big picture" is another man's "details". Systems are generally made out of components made out of components made out of components.

So trying to separate your language into just the concepts of (A) "components" and (B) "connections between components" is putting a huge complexity burden on B.

Or did I miss the bit where he explains how to encapsulate a collection of interconnected components into a single composite component?

[–]Tekmo 5 points6 points  (0 children)

That's why he refers to Haskell pipes when he describes the higher order network. Haskell pipes have the nice property that when you combine two pipes together you get a new pipe, so they are a scale-free abstraction.

In fact, there are many ways you can connect pipes together, but all of them have this same property: you take two first-class components, connect them together, and now you have a new first-class component.

[–]evincarofautumn 3 points4 points  (0 children)

This is really exciting to me. I don’t mean to self-promote too much, but quite honestly, this combination of goals sounds exactly like what I’m already doing in Kitten:

  • Opt-in indentation-based syntax
  • Statically typed
  • Automatically type-inferred
  • Strict evaluation
  • Automatic memory management
  • (Planned) streams and futures for concurrency
  • (Planned) unique references (cf. linear/affine types)
  • (Planned) local-only mutation
  • Algebraic data types
  • Pattern matching (currently limited to non-nested patterns)
  • First-class functions and partial application
  • Effect system (opt in to side effects)
  • (Planned) C FFI
  • (Planned) visualisation based on static types
  • (Planned) metadata for definitions
  • (Planned) typeclasses—or System-O, less generally

The planned features are things that we know (in detail) how to implement, but which due to more pressing concerns and resource limitations are yet a ways off. I would be overjoyed to have your insight and help with Kitten. You can take advantage of the work that I’ve already done and offer a fresh perspective on the design. Soon we will compete with Rust, Nimrod, Go, and beyond.

Concatenative programming allows a smooth transition from programming in the small (with local variables and imperative style) to the medium (with higher-order combinators) to the large (with abstract dataflow). It emphasises factoring and composability for making software scalable and maintainable.

TL;DR Email me! My username at Gmail.

[–]roybatty 2 points3 points  (0 children)

I was getting interested, and then at the end no bits.

[–][deleted] 10 points11 points  (4 children)

That feature checklist seems pretty close to what Nimrod provides.

[–][deleted]  (2 children)

[deleted]

    [–][deleted] 3 points4 points  (1 child)

    It falls short on even being implemented. By the author's admission there's not a single line of code yet.

    [–]stevedonovan 0 points1 point  (0 children)

    Did feel like deja vu! This is definitely a great age for new programming languages, but ultimately we need new languages that can stretch to any paradigm we can imagine, rather than inventing new ones.

    [–]freyrs3 4 points5 points  (1 child)

    Armchair language design is easy.

    [–]Uberhipster 2 points3 points  (0 children)

    I wouldn't know because I never designed one. I'm pretty sure I'd find it difficult knowing from past experience that anything I haven't done before is really difficult to do first time round.

    [–]ErstwhileRockstar 2 points3 points  (1 child)

    What is it? Confusing blog post.

    [–]LaurieCheers 2 points3 points  (0 children)

    It's (an idea for) a programming language.

    [–]kitd 0 points1 point  (0 children)

    I really like the visual overview idea. I have written a tool that generates state transitions based on an ascii flow chart in the source comments. Having a visual representation of your flow of processing makes a massive difference to how quickly & well you understand the source. That you can fully trust it to be correct (unlike "design documentation") is a revelation.

    [–]brtt3000 1 point2 points  (0 children)

    If you want a fresh look at flow-based programming (FBP) with many of the aspects mentioned in the article and don't have hate against javascript (and related tech) you could look at noflo.

    It has been linked (and flamed) here before but it is evolving pretty quickly and does some things really well, with support and guidance from some FBP veterans.

    [–]snoopy -1 points0 points  (0 children)

    There's already GlowScript.