HN Explorer

Ask HN: Programming ideas that redefine the way you look at programming

4 points by rmnull ↗ HN
What are the ideas in programming that once you saw you could never go back looking into other programs the same way. For e.g, one a recent HN thread about units[0] one user shared a F# snippet like this

    unit type Meters = m
    unit type Seconds = s
    val speed = 5.4 m/s
I'm unfamiliar with F# but having units right next to value is something i'll be remembering everyday from now on[1]

Some other ideas that changed the way i look at programs.

* Lisp Macros

* First class functions. Passing functions as a value is something that i do everyday.

* Garbage collection. Not having to worry about memory allocation is such a relief.

The last 2 points are surprisingly a common pattern now, but for someone coming from C[2] and shell scripting its a whole different world here.

======

[0]: https://news.ycombinator.com/item?id=30749134

[1]: In school we were made to write units next to values, Now that ive seen it, i ask myself why don't more languages support this.

[2]: i'm aware of function pointers in C but its something that i rarely used(iirc qsort expected it).

11 comments

[ 2.7 ms ] story [ 34.8 ms ] thread
PaulHoule
Units next to values are expensive. If you had a vector of 10 million lengths and some are in centimeters and others inches and others furlongs the conversions you would have to do to add or multiply these values would cost more than the arithmetic you want to do, certainly you couldn't use SIMD instructions or the GPU to do accelerated math.
elviejo
There are 10 types of developers the optimizers that worry about the impact of storing and processing of a datum. Exemplified by C developers. And the modelers whose main worry is to represent the world in mental model that can fit in or brain, exemplified by Smalltalk developers.

I'm glad both exist.

manx
Immutable data structures. Once you start working with them, it changes your thinking about software architecture. Mutable state is still useful in local high-performance code, but that's rare.
icsa
Views in k/q. A view is like a variable whose value is determined by a dependency expression.

/ any time c changes, f will be updated f::32+1.8c / temp (F) from temp (C)

/ any time m or x or b change, y will be updated y::bm*x

Lots of conditional logic falls away when dependent relationships can be described this way.

[deleted]
(comment deleted)
sargstuff
For non-lisp languages, associative/index array combinations as trees, where terminal nodes are hashes & traverals are topological transform(s) relevant only for a given name space. (instead of functions with side effects)

best with garbage collection support in language so as not to abuse the functional stack.

abrax3141
Lisp. Full stop. (Lisp has had all of your three bullets since 1960 -- although they didn't have explicit macros until somewhat later, the fact that lisp is homoiconic and functional by design directly enabled what amounted to macros.)
icsa
K's coupling of data and user interface elements.

All data can have a gui widget type in its metadata.

The benefit was: * If you changed the widget then the data changed. * If you changed the data then the widget changed.

The layout of the data implied the layout of the widgets.

Using that version of k was the only time that I ever willingly did UI development.

rmnull
i once did gui development in racket/gui. The dependency between widgets and variables is a pain to deal without something like that.

P.S: don't take this to mean i hate on racket, i'm just complaining about the default state of racket/gui, there have been attempts to improve it by 3rd party libraries(https://docs.racket-lang.org/gui-easy/index.html).