HN Theater @HNTheaterMonth

combobulate (alpha quality as of 10/22): source code outline/cliff notes. from github README.rst "Emacs package that provides a standardized framework for manipulating and navigating your source code using tree sitter's concrete syntax tree " -> https://github.com/mickeynp/combobulate

https://www.spacemacs.org/ with https://github.com/emacs-tree-sitter/elisp-tree-sitter then write a iterator/loop query for language(s) editing per https://tree-sitter.github.io/tree-sitter/syntax-highlightin...

tad less installation heavy (sorta) but also makes use of tree-sitter syntax queries : https://www.lunarvim.org (neovim with treesitter syntax)

blockman usage examples: https://www.youtube.com/channel/UC5539gDeAdWqeXcczWuhnBA

Alternative examples / takes (per user interface):

### embedding a block of source code in a document:

  ** carrotsearch.gethub.io/apidocs/code-blocks

  ** https://ckeditor.com/docs/ckeditor5/latest/features/code-blocks.html

### 'colorize blocking' (vs space endenting) :

  ** example code reference coloring: https://www.youtube.com/watch?v=b0EF0VTs9Dc&;list=PLtvX0WpNqnvMQbLB9j4TKbqHMmoLaoOOr

### gui block programming :

  ** https://mblock.makeblock.com/en-us/   

  ** https://developers.google.com/blockly

I went to find the video where I first heard him say something about syntax highlighting is for kindergartners https://www.youtube.com/watch?v=b0EF0VTs9Dc&t=899

It's an unfortunate comment since I struggle with word salad most days. Being able to skim and find certain blocks or aspects of a source file is preferable if I can't remember the name of something right away.

Maybe I can finally have this syntax highlighting style: https://youtu.be/b0EF0VTs9Dc?t=900

⬐ brundolf

The idea is pretty awesome, but my eyes nearly rolled out of my head from the needless condescension at the beginning.

⬐ chewxy

it's just how old people talk. Rob Pike speaks of syntax colouring in the same way - he quotes the Bible.

I don't see it as condescension though. I think it's just a way of speaking.

⬐ brundolf

"[Syntax coloring] is something we put in our text editors to make it easier for kindergarteners to do programming, because each element of the language is a happy bright color so it's easier to recognize which is a variable, or a string, or so on. I don't get a lot of value out of that because I'm... more sort of a grown-up, and a professional programmer, and I really don't need the colors to figure out what's a variable and what's a comment."

This is either some really dry sarcasm that went way over my head, or it's brogrammer phallus-measuring directed at everyone out there who benefits from these kinds of usability features (which is to say, most of us).

⬐ nerdponx

I know plenty of "old people" who don't talk like this. In fact, the "old people" that I respect tend to be a lot more open-minded.

It's one thing to joke about it a little, but this is just arrogance on display with obvious derision for us children who find that traditional syntax highlighting is beneficial.

I recall reading once that Vim tabs were a crutch for people who "can't remember what they're working on". It's the same kind of arrogance and presumptiveness.

⬐ nerdponx

I'm pretty sure you can implement this in Neovim with Tree Sitter now.

This would be a wonderful idea in any programming language.

But I agree with the other commenter that this speaker is really condescending. Not a person I'd want to work with.

⬐ komodo009

nvim-treesitter is pretty promising, do you know if it supports this type of highlighting already?

⬐ cat199

if your mute is on, accompanying audio states:

"You've all seen syntax coloring, right? That's something we put in our text editors to make it easier for kindergardeners to do programming"

:)

⬐ srcreigh

There is an emacs package for this (maybe beta). I can't remember the name of it and Google is failing me.

EDIT: finally found it https://github.com/alphapapa/prism.el

⬐ jackcviers3

Rainbow delimiters mode kind of does this, but doesn't maintain the scope color of referenced variables.

The one thing that made monads clearer for me was this thing https://youtu.be/b0EF0VTs9Dc Monads and Gonads

It's probably condescending for haskellers because it shows that monads are not some enshrined primary concept but just a kind of dumb wrapper you can write in any language and you do when it's useful for you.

⬐ wbl

Except that most commonly used languages dont let you have polymorphic typing so the whole point is lost.

Javascript promises are a kind of monad. Douglas Crockford talks about this in his talk "Monads and Gonads" [1]

[1] https://www.youtube.com/watch?v=b0EF0VTs9Dc

>The biggest real problem I’ve found with large “where” clauses is that they tend to have a lot of implicit dependencies on variables from the enclosing scope.

For me it's always a toss up. I like to make things local where possible to give some indication that the definitions need not be looked over with a fine-toothed comb -- they aren't used extensively. On the other hand, it does often lead to implicit dependencies. It would be nice to have scope highlighting - color every identifier based on the distance from the scope it's defined in. This idea shamelessly stolen from Doug Crockford in https://www.youtube.com/watch?v=b0EF0VTs9Dc

⬐ chriswarbo

Dr Racket has a nice feature where it draws arrows between a variable and its binding site, and between a binding and its use sites; it would be nice to use a similar thing in Haskell.

https://docs.racket-lang.org/drracket/buttons.html#%28idx._%...

⬐ andromeduck

I think something like eclipse's definition window would do a better job.

also, this indirectly reminded me of what I thought to be one of DC's greatest talks: Monads and Gonads (https://www.youtube.com/watch?v=b0EF0VTs9Dc)

> Do I need to know Haskell? Yes.

This is enough for me to reject this blogpost.

No you don't need a specific language to implement any functionality that can be implemented by a turing-complete language.

I watched Crockford's monad talk [1]. He used javascript. The only problem with that talk is that he spent about 10 seconds or less explaining what a monad is (and the rest of the talk on implementation issues and his own perspective, etc, etc).

I'm still waiting for a good monad discussion without CT or Haskell. (this [2] and this [3] look promising, both in python)

[1] https://www.youtube.com/watch?v=b0EF0VTs9Dc

[2] http://www.valuedlessons.com/2008/01/monads-in-python-with-n...

[3] http://www.dustingetz.com/2012/04/07/dustins-awesome-monad-t...

⬐ mightybyte

Hi, I'm sorry you feel that way. Maybe you just aren't my target audience. That being said, Crockford's explanation of monads in that talk was overly simplistic and misses much of the point of the benefit that you get from them in a language like Haskell. And if we're being honest here I think it's safe to say that most programmers wouldn't have even heard of monads if it wasn't for Haskell. I gave a talk at the NY Haskell meetup a few years ago that specifically addresses Crockford's talk in a little more detail [1]. That talk might be about the level you're looking for. There is some Haskell code, but most of the talk should make sense to someone not familiar with Haskell.

[1] https://vimeo.com/59215336

⬐ jimbokun

You need to know Haskell to complete the exercises, not to understand Monads.

⬐ 88e282102ae2e5b

That may be true in principle, but I have been unable to find any resource ever that explains them well. Presumably this is because I don't know Haskell and the only good explanations are in that language.

⬐ banku_brougham

Dude, fine. But the author wrote the tutorial with those assumptions, he's just trying to help you out bro!

⬐ rntz

It's true that you don't need to know Haskell in order to learn about monads, but Haskell is a perfectly reasonable language in which to write a monad introduction.

Haskell is good for learning about monads for the same reasons monads tend to be heavily used in Haskell, but not in other languages. Monads are both part of Haskell's standard library, and have very useful special syntax (do-notation). Writing out monadic code explicitly gets to be a huge pain when using monads in another language. Typeclasses also make it convenient & easy to write code that's generic over any monad.

⬐ imh

>Writing out monadic code explicitly gets to be a huge pain when using monads in another language.

Couldn't any other language have a syntax like

    thing.do(\x -> other thing(x)).do(
    \x -> yet another thing(x)).do(
    a function).do(
    more stuff).do(
    etc)

And then replace "\x -> whatever" with the local language's lambda syntax. The only time you get the painful nested parens is if you want

    thing.do(
    \x -> f(x).do(
    \y -> g(x,y)))

It's not too terribly bad.

⬐ ash

Like JavaScript Promises?

In [this talk](https://youtu.be/b0EF0VTs9Dc?t=15m2s) by Douglas Crockford he talks about syntax highlight being for kids - "that's something we put in our text editors for kindergarteners to do programming...I am more sort of a grown up and a professional programmer so I don't need to colours".

I found it weird he was so deriding towards syntax highlighting.

⬐ pheroden

Low self esteem I'm guessing.

⬐ michaelmrose

He is working backward from his own personal preference and working awfully hard to justify that as if he came to that conclusion for logical reasons.

People often think they are acting logically when frequently they are working backwards to write narratives that justify the way they choose to act.

Here's Douglas Crowford on coloring he'd like to see in his code editor:

https://youtu.be/b0EF0VTs9Dc?t=899

...that's how chaining method calls end up working in most OO languages (take the Scala example in OP's article). And also in Javascript (I can't remember if there is something like `range` in js right now...):

    [1,2,3,4,5,6,7,8,9,10]
      .map(function (x) { return x + 2 })
      .reduce(function (a, b) { return a + b })

so the "." in OOP ends up working like "->" or "->>". Heck, you can make the dot in OOP code behave like anything, even like monadic bind (`>>=` or `do` notation in Haskell), if you do OOP-style-monads in JS: https://www.youtube.com/watch?v=b0EF0VTs9Dc

(off-topic: this is also my main problem with OOP... the "." can actually end up meaning anything practically, as program logic is concerned, it's like some kind of "infinite operator overloading" :) )

⬐ icebraining

But (conceptually) the "." in most OO languages is something that is part of the object it's being applied to, while the -> is something external that one applies to the subsequent expressions. At least, this is what I perceive by looking at the code, and in my opinion, the two concepts don't map intuitively.

⬐ AnimalMuppet

No (at least not in one specific OO language, namely C++).

"foo->" means exactly the same thing as "(*foo)." That is, you use "." when you have an object, and "->" when you have a pointer to an object.

I don't know of any other OO language that uses "->". If there is one, my comments here probably do not apply to it...

(Or were you talking about the "." as used in OO, compared with the "->" as used in Clojure? If so, disregard this comment...)

⬐ icebraining

(Or were you talking about the "." as used in OO, compared with the "->" as used in Clojure? If so, disregard this comment...)

I'm afraid I was :)

I'm unfamiliar with Clojure, but I rather liked Douglas Crockfords comment on code coloring (Lisp) based on scope rather than syntax.

https://www.youtube.com/watch?v=b0EF0VTs9Dc&t=15m30s

Douglas Crockford seems to think otherwise: http://www.youtube.com/watch?v=b0EF0VTs9Dc

⬐ copergi

He also gets a lot wrong in that talk, so that doesn't seem like a particularly compelling case.

⬐ alanning

Could you point out some of the issues you noticed in the talk? (Asking from the point of view of someone curious about monads.)

⬐ tel

I'm not interested in watching it again, but my impression from the last time is that he's about 3/5ths of the way to "true monad nirvana" if such a thing were a place. There are higher levels above that where we start to really understand the category theoretic and PLT theoretic mechanism of monads, but I think that's truly a different tier.

⬐ habitue

From watching half of it, he mistakes monads for being a trick to avoid Io, which is not true. Io really does happen in Haskell, it is just contained. Also he mentions types not being necessary to understand monads, but immediately launches into a description of the bind and unit functions by, you guessed it, stating what the types of the function's were and what kinds of things they returned (I.e. the exact thing he said he wouldn't talk about on the previous slide).

That being said, I liked his reworking of bind to be a method on an object. I agree monadic computation is tedious to read when you don't have an infix bind operator, and his trick of turning bind into a method solves that pretty well in a language like JavaScript.

I think he's probably overstating the case that what he calls ajax chaining is always monadic (but what most of us who didn't write a competing library would call jquery style method chaining). I would guess most implementations of this kind of APIs do not adhere to the monad laws.

"Monads for JavaScript Programmers"

Just as the talk he refers to (I've seen it and it's ok)... It's for JavaScript programmers):

https://www.youtube.com/watch?v=b0EF0VTs9Dc

So unless there's a 1-to-1 mapping between "Normal Programmers" and "JavaScript" programmers this title is quite misleading.

⬐ VeejayRampay

And I wonder what "normal" programmers even means.

Is it "normal" as opposed to "exceptional/enlightened", to "anormal", to "strange". Doesn't compute.

⬐ davvid

I found the bit on "Context Coloring" very interesting (around 15:00). I want my editor to do that!