Hacker Newsnew | past | comments | ask | show | jobs | submit | axelerator's commentslogin

Definitely some good reminders in there!

> But the converse: that successful outcomes are also the result of gambles; is not widely appreciated.

This statement however I would challenge: There is the whole ‘build fast and break shit’ culture that bets exactly on that outcome.


> There is the whole ‘build fast and break shit’ culture that bets exactly on that outcome.

Mark Zuckerberg was 13 when this was published, so I'm not sure that's accurate


There are bunch of good UX principles baked into HTML and CSS. Plus to become good at HTML and CSS you will be exposed to a lot of UX talk as well.

So one could argue it's really hard to get really good at HTML and CSS and not care about UX at all.

But yes, a fool with a tool is still a fool - if that's the point you're trying to make.


Not directly making that point.

Just that a lot of programmers aren't necessarily known for their design aesthetic.

So you could 'not be a fool', and be very good at HTML/CSS, and yet not really understand or care about color, flow, layout.

But, to your point, surely they will absorb something in the process. But it is far from a given.

Isn't this the entire argument between Apple-Microsoft, Jobs-Gates?

Gates isn't a fool, neither are MS programmers, but they aren't known for good 'ux designs'

There are a lot more technology experts than good Design experts.


A web interface for infrared remote controls https://www.instructables.com/Web-IR-Remote-With-Esp8266-Nod...


> Well... no. Engineers are more efficient in their own styles. Realistically, I've wasted hours setting up my editor at each new job / each project to get on board with the style

I disagree for two reasons:

1. Optimizing for what each dev is used to is optimizing for a local maximum. If they’re THAT good it won’t take them long to adjust to new defaults. Good engineers should be able to pick up a new lang quickly so some changes in the context of a language should not bog them down significantly in the long term.

2. The overly long time it took to set up tooling in a particular company or language do not outweigh the bigger advantage of being able to quickly get a grasp about what a piece of completely unfamiliar code does.


Very inspiring! I just started out to play around with the wave function collapse algorithm [1]. I'm in the middle of porting it to a cube based 3d grid. And now I'm wondering what a triangle based volume presentation would look like

[1] https://github.com/axelerator/wave-function-collapse-2d


How do you plan to fill 3D space with ‘triangles’?

You can’t do that with tetrahedrons. You can use triangular prisms, but IMO, that’s cheating. You can also split a cube into six pyramids with a square base and height ½, but I don’t think that’s a natural way to fill space.

Looking at https://mathworld.wolfram.com/Space-FillingPolyhedron.html, the Truncated Octahedron probably is the nicest alternative to the cube.


I think this question is sort of another way to phrase, "What are the crystal systems [or possibly lattice systems] other than primitive cubic?" And the answer is in https://en.wikipedia.org/wiki/Crystal_system; there are 6 or 31 answers depending on how you look at it. Or maybe the question is "What are the 3-honeycombs other than the cubic honeycomb?" which is discussed in https://en.wikipedia.org/wiki/Honeycomb_%28geometry%29 and to which there are an infinite number of answers.

Crystal systems are usually described in terms of point lattices, while you're talking about polyhedra, but the Voronoi polyhedra of the points in the lattice are the polyhedra you're looking for. (This is mentioned at the end of the Wolfram™Ⓡ MathWorld™Ⓡ article you linked.) One of my favorites is the cuboctahedral honeycomb corresponding to hexagonal close-packed crystals.

Even within cubic crystals, you could reasonably argue that face-centered cubic crystals "fill[] 3-D space with ‘triangles’".

Honeycombs do not, as I understand it, have to be periodic. In particular, any 3-D rep-tile can be used to tile space in a manner similar to the Penrose tiling, and usually the result is aperiodic. I wrote a 2-D demonstration of this process is at http://canonical.org/~kragen/sw/dev3/skitch#!ffffrrrfffffrrr...].


From Wikipedia: The tetragonal disphenoid tetrahedral honeycomb is a space-filling tessellation (or honeycomb) in Euclidean 3-space made up of identical tetragonal disphenoidal cells.

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


I once did a 3d-space representation with https://en.wikipedia.org/wiki/Rhombic_dodecahedron

but in the end it turned out to be easier to just supersample everything down to cube grid, then put some n-vectors on top than to explain everyone how to calculate stuff in that grid.

Still have couple dozen ~3" cardboard ones somewhere from when I tried to understand how exactly do they stack. Made a nice lamp when stuffed with LEDs.


> Truncated Octahedron

looks to me like they fill space pretty nicely as an offset of cubes, in the same way as hexgrid is sort of an offset of squares

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


https://mathworld.wolfram.com/RhombicDodecahedron.html

Rhombic dodecahedron looks quite nice.

And you could mix it with cube grid for artificial structures in your world.


I think 3D modelling lends itself exceptionally well to the functional programming style. Rusts syntax is heavily influenced to solve a breadth of system level problems that don't exist in the "application" space this is solving.

I would argue such a system would be best implemented in a language that only has expressions. For example Elm has a wonderful geometry library [1].

[1] https://package.elm-lang.org/packages/ianmackenzie/elm-geome...


Fornjot is architected to be language-agnostic. Rust is just the easiest language to support, given that the rest of the project is written in it too.

I (author of Fornjot) don't have any near-term plans to add support for other languages, but I hope that people will start experimenting (and someone already has: https://github.com/WeirdConstructor/Fornjot/tree/wlambda_int...).


The FP approach has some readability limitations, for example flexbox-like distribution of multiple elements over a distance requires some heavy recursion.


I always say my appreciation for functional programming comes from having spent enough time in imperative hell.

That being said I think learning programming in an "expressions only" environment can enable the student to deal with more complex problems earlier, merely by making certain types of errors impossible.

I think the Elm programming language is the sweet spot for that.

- it does have elegant (Haskell like) syntax

- it has still a simple syntax because it deliberately omits certain features (namely typeclasses, do-notation)

- it has a self contained build system (compiler, package manager, repl, dev server) with a rich ecosystem of libraries

- it is comparatively easy to ship something tangible because it compiles to JS for the browser


But keyboards are not. Even if I’d be able to convince the maintainers of my favorite programming language to also accept some Unicode glyph as synonym to ‘==‘ how do I type it? Ligatures might not be ‘the right’ solution, but they are a highly efficient approximation. Also the cost of reversing the decision to use them is basically zero.


That's what I said. To the programming language it's just a token and representing that with a single ligature is fine.

I replied to a comment, that the document is character-based and therefore ligatures are inherently wrong.


I recommend trying to get started with webGL Elm [0]. It's a language that compiles to JS to run in the browser. It's a functional language and saves you from having to deal with most of the historical baggage of JS.

[0] https://lucamug.medium.com/3d-graphics-in-the-browser-with-e...


I'm kind of sad they write such an article without mentioning the demoscene.

http://demoscene-the-art-of-coding.net/the-demoscene/


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: