X and NeWS history - <AUTHOR> http://minnie.tuhs.org/pipermail/tuhs/2017-September/010471.html <comment><USER2> The comment about how X is really just a distributed database system with occasional visual side effects that could be reduced down to 10 or so API calls gives us a glimpse as to what life could have been.

It's a shame that all of the X replacements on the horizon also ditch the network transparency part, even though that's been a killer feature for me. I hate how much of a hack Remote Desktop is on Windows machines.

<comment><USER3> > It's a shame that all of the X replacements on the horizon also ditch the > network transparency part, even though that's been a killer feature for me.

I've used ssh -X many times in my life, but at the same time, I understand why network transparency doesn't make as much sense anymore.

Classically, the X protocol kept a huge amount of state on the server, and clients would just send small requests to manipulate that data. Drawing would take place server-side, and it was relatively simple drawing at that, since UI needs were fairly modest. Text rendering occurred on the server with small strings sent from the client. And overall, it made sense to send a small amount of data to produce a large amount of graphics.

These days, however, rendering occurs almost exclusively on a combination of the client and the GPU. Everything takes place via large memory buffers, and compositing. And pushing those over the wire doesn't work nearly as well; if you're going to do that, you need protocols designed for it, with compression and delta-encoding, much like modern video codecs (but optimized for remote- desktop).

So I think it makes sense that network transparency is being rethought, in favor of protocols that look a lot more like remote-video (and remote-audio).

<comment><USER4> People not familiar with X reading the above (which is correct) might miss that client/server is reversed from the way most people think about it. For X, the server is the system where the display/keyboard/UI is physically attached and the client is the host (remote host for this discussion) where the application is actually running.

<comment><USER5> I don't know why this is confusing to people, at least if they understand sockets. The display server does listen(2). The application does connect(2). Why is that hard?

Windows and Mac use similar terminology to "display server" too, but I guess those are proprietary components that few people look into...

<comment><USER6> I understand sockets and I understand how X works, and I think it's confusing and stupid. It places unnecessary emphasis on an implementation detail that is unimportant to the end user.

<comment><USER5> Then say "app" or "program" instead of "x client" and nobody is harmed ... If people say "x client" it's usually in a more architectural, less colloquial context to begin with.

</comment></comment></comment></comment></comment></comment><comment><USER7> "Had he done some real design work and looked at what others were doing he might have realized that at its core, X was a distributed database system in which operations on some of the databases have visual side-effects. I forget the exact number, but X includes around 20 different databases: atoms, properties, contexts, selections, keymaps, etc. each with their own set of API calls. As a result, the X API is wide and shallow like the Mac, and full of interesting race conditions to boot. The whole thing could have been done with less than a dozen API calls."

To that end, one of the weirder and cooler re-implementations of NeWS was Cogent's PIX for transputers. It was basically a NeWS-like multiprocessing PostScript interpreter for Transputers, with Linda "tuple spaces" as an interprocess communication primitive:

[http://ieeexplore.ieee.org/document/301904/](http://ieeexplore.ieee.org/document/301904/)

The Cogent Research XTM is a desktop parallel computer based on the INMOS T800 transputer. Designed to expand from two to several hundred processors, the XTM provides a transparent distributed computing environment both within a single workstation and among a collection of workstations. Using Linda tuple spaces as the basis for interprocess communication and synchronization, a Unix- compatible, server-based OS was constructed. A graphic user interface is provided by an interactive PostScript window server called PIX. All processors see the same set of system services, and within protection limits, programs capable of using many processors can spread out over a network of workstations and resource servers, acquiring the services of unused processors.

[http://wiki.c2.com/?TupleSpace](http://wiki.c2.com/?TupleSpace)

[https://en.wikipedia.org/wiki/Tuple_space](https://en.wikipedia.org/wiki/Tuple_space)

</comment><comment><USER8> > I have a section in the book that I'm writing where I talk about how to > design a good API. I pose the question of why none of the original Apple Mac > API published in 1985 taking about 1,200 pages is in use today whereas > almost all of the UNIX V6 API published in 1975 taking 321 pages is still in > use and has been copied by many other systems. I'm sure that everyone on > this list knows the answer.

I'm not sure I do. But it does seem like a good question.

Also:

[http://www.art.net/~hopkins/Don/unix- haters/x-windows/disast...](http://www.art.net/~hopkins/Don/unix- haters/x-windows/disaster.html)

<comment><USER9> My guess is that the original Mac OS provided a great GUI, but not much of an OS. It loaded a single application at a time that had access to all of memory. That's why it had desk accessories, to give you apps you could use without quitting the main application. It had handle based memory management so the OS could move memory blocks more contagiously to create enough open space for new memory allocations.

Over time they added cooperative multitasking, which meant the foreground app had to consciously give time to let background apps do stuff.

But they could never build a real OS with security and memory protection out of it. So Apple bought NeXT to get industrial strength unix as their core OS, and switched all Apple development to NeXTStep, or at least the modern derivative of it, called Cocoa.

My dust covered Inside Mac volumes were made useless nearly 20 years ago.

<comment><USER10> _"Over time they added cooperative multitasking"_

You may know, but for readers who don't: _"they"_ didn't, Andy Hertzfeld did ([https://www.folklore.org/StoryView.py?story=Switcher.txt](https://www.folklore.org/StoryView.py?story=Switcher.txt))

It helped that he had intimate knowledge of the Mac operating system's internals, but many of them were documented in Inside Macintosh, and others could have been found with (quite) a bit of effort; one didn't have to be at Apple or even have access to the system's source code to implement that.

And those volumes aren't useless; they are reminders of about the last time hacking an OS was fun :-;

<comment><USER11> What is fun is the Switcher/Multi-Mac debacle. Notice that it was mentioned that "I knew that releasing it would have me having to keep up with all the new ROM releases from Apple in the future." At the time, even with the 128K ROM I think they still had to put special code to support Switcher into there (Andy was also working on the Font Manager at the time).

</comment></comment></comment></comment><comment><USER12> This is also an important example of how limiting an anti-social attitude can be when trying to collaborate and have a large affect on the world. As brilliant as Jon is, he wasted an inordinate amount of time making up for constantly insulting people, places, and approaches. (Even today he couldn't avoid insulting all of Tulsa OK).

Imagine where windowing systems could be if his brilliant work, API thoughts, and insights weren't delivered with insults, arrogance and vitriol.

At the end it is sad that he was proud of being right even though he was an _hole (his word). It could have been that he was right and his best ideas were in common use.

<comment><USER13> I didn't realize people were so sensitive in the field. Compared to Linus, Theo de Raadt, Richard Stallman, etc, Jon seemed to be cruising at a comfortable level of Germanic straight-forward truth-telling, no real a __holishness I could detect. Guess I should reset my etiquette and politeness filters.

<comment><USER14> I note that the people you name all built their communities through work they did well outside the corporate world.

<comment><USER15> And at least two of them have a undeserved reputation.

<comment><USER13> You mean Theo and Linus? Yes.

<comment><USER16> Theo's reputation is very well deserved.

</comment></comment></comment></comment></comment></comment><comment><USER17> I've read some of Don Hopkins' comments about all the cool things that were done with PostScript running in the NeWS server. I wonder, if NeWS had survived long enough that Sun had to add accessibility for people with disabilities (to sell to governments and schools if nothing else), how would they have done it? Today, the current state of the art is very chatty IPC (meaning tens of microseconds per cross-process call), partially assisted by bulk fetching and caching. To appreciate how bad that can be, think about a screen reader making at least one IPC call per word when reading text, to ask the application about word boundaries and bounding rectangles. That's a problem I hope to solve someday. In a parallel universe, though, maybe the screen reader is running inside the NeWS server, in the same address space as a PostScript-based UI toolkit.

<comment><USER7> I've written up some thoughts and discussions about accessibility and JavaScript, and discussed them a few times here!

I discovered the great work of Morgan Dixon and James Fogarty, which proves that you can do some amazing things with screen scraping, pattern matching, visual deconstruction, augmentation and reconstruction! His work needs to be combined with platform specific accessibility APIs via JavaScript.

I'm proposing "aQuery", a high level scriptable accessibility tool that is to native user interface components like jQuery is to DOM, for selecting and querying components, matching visual patterns, handing events, abstracting platform dependencies and high level service interfaces, building and scripting higher level widgets and applications, etc.

[http://donhopkins.com/mediawiki/index.php/AQuery](http://donhopkins.com/mediawiki/index.php/AQuery)

[https://news.ycombinator.com/item?id=11520967](https://news.ycombinator.com/item?id=11520967)

Morgan Dixon's and James Fogarty's work is truly breathtaking and eye opening, and I would love for that to be a core part of a scriptable hybrid Screen Scraping / Accessibility API approach.

Screen scraping techniques are very powerful, but have limitations. Accessibility APIs are very powerful, but have different limitations. But using both approaches together, screencasting and re-composing visual elements, and tightly integrating it with JavaScript, enables a much wider and interesting range of possibilities.

Think of it like augmented reality for virtualizing desktop user interfaces. The beauty of Morgan's Prefab is how it works across different platforms and web browsers, over virtual desktops, and how it can control, sample, measure, modify, augment and recompose guis of existing unmodified applications, even dynamic language translation, so they're much more accessible and easier to use!

[https://news.ycombinator.com/item?id=12425668](https://news.ycombinator.com/item?id=12425668)

This link has the most up-to-date links to Morgan's work, and his demo videos!

[https://news.ycombinator.com/item?id=14182061](https://news.ycombinator.com/item?id=14182061)

[https://prefab.github.io/](https://prefab.github.io/)

Prefab: The Pixel-Based Reverse Engineering Toolkit Prefab is a system for reverse engineering the interface structure of graphical interfaces from their pixels. In other words, Prefab looks at the pixels of an existing interface and returns a tree structure, like a web-page's Document Object Model, that you can then use to modify the original interface in some way. Prefab works from example images of widgets; it decomposes those widgets into small parts, and exactly matches those parts in screenshots of an interface. Prefab does this many times per second to help you modify interfaces in real time. Imagine if you could modify any graphical interface? With Prefab, you can explore this question!

[https://www.youtube.com/watch?v=w4S5ZtnaUKE](https://www.youtube.com/watch?v=w4S5ZtnaUKE)

Imagine if every interface was open source. Any of us could modify the software we use every day. Unfortunately, we don't have the source.

Prefab realizes this vision using only the pixels of everyday interfaces. This video shows how we advanced the capabilities of Prefab to understand interface content and hierarchy. We use Prefab to add new functionality to Microsoft Word, Skype, and Google Chrome. These demonstrations show how Prefab can be used to translate the language of interfaces, add tutorials to interfaces, and add or remove content from interfaces solely from their pixels. Prefab represents a new approach to deploying HCI research in everyday software, and is also the first step toward a future where anybody can modify any interface.

More Prefab demos:

[https://prefab.github.io/videos.html](https://prefab.github.io/videos.html)

<comment><USER17> Fascinating! What are some of the limitations of screen scraping that are addressed by accessibility APIs? Is it primarily the unreliability? Do you envision using an accessibility API as the primary source of information, with screen scraping as a fallback?

<comment><USER7> Accessibility APIs expose lots of rich high level information like associating a label with a widget (to name one simple example, but it gets MUCH more complex than that). And of course the position and meaning and state of each object on the screen.

There needs to be a higher level scriptable way to get a handle on all that complexity, like jQuery helps automate the creation and manipulation and abstraction of HTML DOM and events and handlers.

PhoneGap/Cordova plugins and NativeScript both take a similar approach: they have a generic Objective C / Java / Whatever <=> JavaScript bridge that lets you directly call all (or most) of the native APIs, including accessibility, directly on each platform. Then you write higher level platform independent APIs on top of the native APIs in JavaScript, a different one for each platform, but the same high level interface to JavaScript programmers.

[https://docs.nativescript.org/core-concepts/accessing- native...](https://docs.nativescript.org/core-concepts/accessing-native-apis- with-javascript)

I would try to use the native API as much as possible since they're precise yet tedious. It should have a platform-independent accessibility-specific selector language like xpath or jQuery selectors, which should be implemented efficiently in native code like querySelector. The pattern matching engine would send asynchronous events back to JavaScript. You could write JavaScript handlers for patterns of pixels as well as accessibility path patterns appearing and disappearing, like jQuery lets you bind handlers to patterns of DOM elements that don't exist yet, instead of concrete existing elements. Those handlers would create higher level widgets that could manage those existing pixels and widgets. (Like recognizing a youtube video player in any web browser window, and wrapping it in an aQuery widget implementing an abstract VideoPlayer interface, for example.)

Of course calling the native accessibility API is lighter weight than screen scraping and pixel matching, and you could use the native API to drill down to just the region of pixels you want to match or screencast, to minimize the amount of screen scraping and pixel matching required.

</comment></comment></comment></comment><comment><USER7> "A couple of decades ago I bough a Sun Ultra-60 and asked whether it was worth paying for the dual processor version. The answer that I got was "Yes. You need one processor to run X and another for everything else."

People cursed with diskless Sun 3/50's would run xterms and emacs's across the net on each other's workstations instead of locally. It was noticeably less sluggish, because you didn't get hit with all the heavyweight process context switching between X clients and server every keystroke.

</comment><comment><USER18> > The only really worthwhile thing about X was the distributed extension > registration mechanism. All of the input, graphics and other crap should be > moved to extension #1. That way, it won't be mandatory in conforming > implementations once that stuff was obsolete. As you probably know, that's > where we are today; nobody uses that stuff but it's like the corner of an > Intel chip that implements the original instruction set.

On the other hand, all of the input, graphics and "other crap" being mandatory means that as a developer you can pretty much guarantee that they are there and if you care about having your stuff work everywhere (well, everywhere X is available anyway) you can simply rely on that without having to support a bunch of different APIs that may or may not be there (see the audio situation a few years ago in Linux).

(also FWIW a lot of people use the X primitives, not everyone uses Gtk or Qt)

<comment><USER19> I'm not quite sure I believe that a lot of people use the X primitives. The alternative to Gtk and Qt is most often not raw Xlib. There are alternative toolkits such as Motif, Xt. And then graphics abstractions such as SDL. Obviously all of these (including Gtk and Qt) use at least some of the X primitives in their rendering or themeing engines, but direct use of Xlib primitives is quite rare. And I think the whole point of the argument is that the commonly used primitives today are things like XRENDER, which aren't really primitives since they are an extension. Precisely the point being made.

Basically, name me an app that uses solely X11 primitives without the use of any extensions and no overlying library over libX11 (and no, xclock doesn't count)

<comment><USER18> Of course i include using toolkits that themselves use X primitives, not only using Xlib directly :-).

For example my own Little Forms library [0] uses the X server's drawing and text operations (you can use Xft instead, it is a build option, but you can also make a static library for binaries that rely only on xlib and nothing else).

[0] [http://runtimeterror.com/rep/lforms](http://runtimeterror.com/rep/lforms)

</comment></comment></comment><comment><USER20> DonHopkins is on HN from time to time, he's always full of things to say about this. Waiting for the wall of history :)

</comment><comment><USER7> John Steinhart is outstanding in his field!

Sometimes he's even out driving a tractor in his field! ;)

<comment><USER13> In that thread, it mentiond that NeWS had "problems". Can you tell us what those problems were?

<comment><USER7> I don't know where to begin, or when to stop, so I'll pick something at random and jump around.

NeWS 1.1 was layered on top of PixRects (the graphics library that SunView was built on top of), which gave it the weird limitation that sub-windows could not be positioned above or to the left of their parents (sub-window coordinates were unsigned), which was a huge pain in the ass for making all kinds of user interfaces.

X11/NeWS solved that problem by having a much nicer PostScript graphics renderer and compositor, but it came with its own set of problems, many having to do with being nailed together with a X11 server with a totally different graphics model and approach to life.

But there were some really cool things you could do with X11 and NeWS together, like managing X11 windows with NeWS frames (which could have non- rectangular windows like jutting title tabs, round pie menus, panning virtual desktops, rooms, etc).

Another important point is that running the window manager in the same heavy weight Unix process as the window server saves an astronomical number of costly context switches, and results in much smoother user interface with silky local feedback. Plus it's extensible and customizable and drawn in PostScript.

Here's a demo of NeWS window frames with tabs and pie menus. We used those to made an ICCCM X11 window manager written in PostScript (that Sun never released) that let you use those tabbed window frames and pie menus and other NeWS components to manage all of your X11 windows (and use them as your default frame for NeWS apps too, of course), seamlessly integrating X11 and NeWS apps together.

[https://www.youtube.com/watch?v=tMcmQk-q0k4](https://www.youtube.com/watch?v=tMcmQk-q0k4)

Here are some flames and notes I wrote years ago about X11 and NeWS window management -- the "OWM" section is about the NeWS X11 window manager. It covers some of the political and technical problems we had integrating X11 and NeWS. Window management is a surprisingly contentious issue! Everybody wants to be on top.

[http://www.donhopkins.com/home/catalog/unix- haters/x-windows...](http://www.donhopkins.com/home/catalog/unix- haters/x-windows/i39l.html)

Basically, we didn't want to put our round NeWS pie menus and pizza windows inside of their rectangular X11 ICCCM window frames, because it would have been better for everyone the other way around.

[http://www.donhopkins.com/home/catalog/images/pizzatool.gif](http://www.donhopkins.com/home/catalog/images/pizzatool.gif)

Josh Siegel wrote this beautiful PostScript tour de force swan song for X11/NeWS, an ICCCM window manager that actually worked quite well, with special window subclasses to support all the OPEN LOOK dialog types and window frame features through their standard X11 ICCCM properties! Check out "ClassX11ManagerMixin", which is what it sounds like. It's mixed into FavoriteBaseWindow, which can be redefined to the custom ClassTabBaseWindow supporting tabs and pie menus, shown in the above video, or any other kind of frame you want to wrap around X11 windows:

[http://www.donhopkins.com/home/archive/NeWS/owm.ps.txt](http://www.donhopkins.com/home/archive/NeWS/owm.ps.txt)

It was a proof of concept, which we wanted to take a lot further by implementing a HyperCard-like user customizable persistent window manager with HyperLook. So users can edit and build their own custom window frames by copying, pasting and configuring scriptable components from object warehouses, edit and extend the user interfaces of running apps, and make high level task- oriented interfaces by composing widgets and apps into "cards", "backgrounds", "stacks" and optional network "clients". But that's not how things turned out. ;/

[http://www.donhopkins.com/home/catalog/hyperlook/index.html](http://www.donhopkins.com/home/catalog/hyperlook/index.html)

[http://www.donhopkins.com/home/catalog/hyperlook/Warehouse1....](http://www.donhopkins.com/home/catalog/hyperlook/Warehouse1.gif)

[http://www.donhopkins.com/home/catalog/hyperlook/ButtonIdeas...](http://www.donhopkins.com/home/catalog/hyperlook/ButtonIdeas4.gif)

[http://www.donhopkins.com/home/catalog/hyperlook/TalkInterfa...](http://www.donhopkins.com/home/catalog/hyperlook/TalkInterfacing.gif)

[http://www.donhopkins.com/home/catalog/hyperlook/TalkRunTime...](http://www.donhopkins.com/home/catalog/hyperlook/TalkRunTime.gif)

I'll excerpt the relevant parts of the i39l flames:

Who Should Manage the Windows, X11 or NeWS?

This is a discussion of ICCCM Window Management for X11/NeWS. One of the horrible problems of X11/NeWS was window management. The X people wanted to wrap NeWS windows up in X frames (that is, OLWM). The NeWS people wanted to do it the other way around, and prototyped an ICCCM window manager in NeWS (mostly object oriented PostScript, and a tiny bit of C), that wrapped X windows up in NeWS window frames.

Why wrap X windows in NeWS frames? Because NeWS is much better at window management than X. On the surface, it was easy to implement lots of cool features. But deeper, NeWS is capable of synchronizing input events much more reliably than X11, so it can manage the input focus perfectly, where asynchronous X11 window managers fall flat on their face by definition.

Our next step (if you'll pardon the allusion) was to use HyperNeWS (renamed HyperLook, a graphical user interface system like HyperCard with PostScript) to implemented a totally customizable X window manager!

Some notes about OWM

OWM is the "Open Window Manager" we prototyped in NeWS. We enhanced the NeWS window frames so they sported indexing tabs, pie menus, rooms, and a scrolling virtual desktop. Many of our enhancements were separatly developed, and plugged together orthogonally like legos. All NeWS applications could use these fancy frames, and the Open Window Manager wrapped X clients in the same frames that NeWS windows got!

This way, factoring the window frames out as a part of the toolkit, and implementing the X window manager separately, NeWS applications don't have to know a thing about X window management, and X clients can go on doing the same nasty things they've always done, and everybody get the benefits of dynamic extensibility, and a consistent user interface, by using the default window class!

X11 window managers must grab the server in order to animate rubber-band feedback over the screen when resizing and moving windows. This grabbing causes many problems with NeWS synchronous interests, that can be demonstrated by pressing the "Help" key while dragging out a rectangle on the root background. NeWS can do a much better job at managing global resources in the server because it is in the same address space and it has facilities like the overlay plane specifically designed to implement such window management functions, without even grabbing the server. This antisocial server grabbing behavior is just one symptom of a general class of problems with external X window management, including other important issues such as keyboard and colomap focus.

<comment><USER21> > X11 window managers must grab the server in order to animate rubber-band > feedback over the screen when resizing and moving windows.

I wonder how the comparison between X11 & NeWS works once when switches to tiling window managers, which require much less work & chrome from the WM.

If tiling WMs favour the X model, I wonder if the real reason so many of us like them is that they are faster, rather than tiling being a better paradigm. I suspect that's not the case — at this point, tiling really feels better to me — but maybe it is?

<comment><USER7> I think the benefits of extensibility far outweigh any differences from whether the window manager supports tiling or overlapping windows. Ideally it should be general purpose enough to support both.

Having an extensible window server enables you to use simpler but powerful primitives (X windows -vs- NeWS canvases, or server grabs + XOR RasterOps -vs- overlay canvases and hardware overlay planes), then implement the higher level stuff flexibly in software: see my other message about the complexity of X window borders, backgrounds and shapes, and how it makes shaped windows unbelievably complicated, even though nobody actually ever needs to use that complexity.

NeWS canvases don't need special built-in borders, because the PostScript interpreter and stencil-paint graphics model's clipping path elegantly solves the problem that X window borders were trying to solve (but didn't solve well enough for anyone to ever use), and solve many more problems in a much more general way.

NeWS had an overlay canvas for non-destructively drawing rubber band feedback over the desktop, which used hardware graphics planes if available, or fell back to using a display list and XOR RaserOps on monochrome or simple 8 bit displays.

Some of the popular Sun color framebuffers (cgsix and gx maybe?) had 8 bits of color pixles and a two bits of overlay planes for cursors and black-and-white windows. SunView knew how to use it for the cursor and light weight monochrome windows, and NeWS used it for the overlay plane, which was perfect for window management and rubber band feedback.

Drawing the cursor in the overlay plane actually sped up graphics performance a surprising amount, since the drawing code didn't have to always check if the cursor was overlapping where it was about to draw, then hiding and redrawing it before and after drawing anything on the screen under the cursor.

NeWS could directly open framebuffers on the overlay plane (1 bit black and white) and overlay enable plane (1 bit that switches between the showing the black and white overlay plane, or showing through to the color framebuffer). Then you could draw on the overlay enable plane to flip between the black and white and color framebuffers on a per-pixel bases (useful for making rubber bands, text labels, 50% checkerboard shadows and highlights, etc).

SGI's 4Sight (their own port of NeWS 1.1 that they integrated with X11 and GL, before Sun's X11/NeWS) also supported hardware overlay planes, and used them for the pop-up menus, so it didn't have to repaint the thick 24 bit graphics underneath the thin monochrome menus when they popped down. My NeWS pie menu code "just worked" in the overlay plane with only a little modification, except that I had to special-case the color wheel pie menu to not use the overlay plane, because the overlay planes weren't allowed more than three colors (black, white, one user defined color, and transparent).

If you're into the history of window management, here's some fascinating stuff about the evolution of window managers, including Andrew, which is a tiling window manager that Gosling and Rosenthal worked on at CMU before NeWS. It also discusses and compares PERQ PNX, APOLLO, SunWindows, MG-1, Sapphire, BLIT, Smalltalk, DLISP, Interlisp-D, Tajo/Mesa, Cedar Docs and Viewers, Star, Viewpoint, and even SunDew (NeWS).

"Methodology of Window Management": [http://www.chilton- computing.org.uk/inf/literature/books/wm/...](http://www.chilton- computing.org.uk/inf/literature/books/wm/overview.htm)

By F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams. 29 April 1985. This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme. The Proceedings were later published by Springer-Verlag in 1986.

My favorite chapters:

"A Comparison of Some Window Managers" by Tony Williams: [http://www.chilton- computing.org.uk/inf/literature/books/wm/...](http://www.chilton- computing.org.uk/inf/literature/books/wm/p003.htm)

"Ten Years of Window Systems - A Retrospective View" by Warren Teitelman: [http://www.chilton- computing.org.uk/inf/literature/books/wm/...](http://www.chilton- computing.org.uk/inf/literature/books/wm/p004.htm)

"SunDew - A Distributed and Extensible Window System" by Games Gosling: [http://www.chilton- computing.org.uk/inf/literature/books/wm/...](http://www.chilton- computing.org.uk/inf/literature/books/wm/p005.htm)

"User Interface Working Group Discussions": [http://www.chilton- computing.org.uk/inf/literature/books/wm/...](http://www.chilton- computing.org.uk/inf/literature/books/wm/p017.htm)

"User Interface Working Group Final Report": [http://www.chilton- computing.org.uk/inf/literature/books/wm/...](http://www.chilton- computing.org.uk/inf/literature/books/wm/p018.htm)

Here is some of the ui working group discussion specifically about tiling windows:

17.2 INTERFACE TECHNIQUES

Some of the issues supplied to the Working Group were felt not to be issues at all; as an example, tiled and overlapped windows were seen to be merely options that the user interface designer could use if appropriate. Indeed, a user connected to more than one host, one providing a tiling environment and the other not. might well have both mechanisms to interact with at the same time.

Window grouping and subwindows received some attention. A subwindow is not necessarily identical to a window: for example a subwindow receiving input it does not understand refers it to the parent for treatment, and if a parent window is deleted then so are its subwindows. Subwindows in some systems can overlap. while others permit only tiling. Title lines, which can be considered as a form of subwindow. may need to be accessible to the application.

</comment></comment></comment></comment></comment><comment><USER14> Through most of that article I was thinking "Yep, that's the kind of train- wreck you get when you design by committee, or worse by political need".

But toward the end, he says that the particular _kind_ of technical train- wreck that they got was similar to the Mac API (presumably the this means the pre-OS X OS). _" [As a resulting of accidentally being lots of databases] the X API is wide and shallow like the Mac, and full of interesting race conditions to boot."_

Anyway, I didn't think that design by committee was one of Apples weaknesses.

</comment><comment><USER22> still better than web apps.

</comment><comment><USER23> I doubt it will come as a surprise to anyone that X was fundamentally ill conceived from the very beginning. It's one of those unfortunate side effects of unintended consequences that Unix history saddled us with it for twenty years longer than we'd ideally have wanted.

It fascinates me that something so widely regarded as Bad and Wrong, proved so hard to replace when it's baked into a system. I think there's a cautionary tale about the necessity of getting your core APIs right, because you might never be able to get rid of them.

<comment><USER24> Having used a multitude of OSes since the 80's and having digital archeology as one of my hobbies, I think it applies to everything in UNIX's design.

<comment><USER13> I would like to hear more. The Unix core API is pretty simple and durable; what was better than it? Other than Plan9? SmallTalk doesn't really count.

<comment><USER24> For starters having been written in C, after the Assembly and B rewrites, when we already had safer systems programming languages in the early 60's.

IBM for example did most of their RISC research with an OS written in PL/8, where they prototyped many ideas about modular compilers, a few of them visible in how LLVM works.

Then by being a plain CLI based OS versus what was being done at Xerox PARC with Xerox Star and Pilot (done in Mesa).

NeXTSTep was probably the only variant that got close of the Mac, Amiga and Atari multimedia capabilities, and even it wasn't a pure UNIX, rather used it as a means to bring applications into the NeXT world.

Many mainframe ideas about OS security are still not part of any UNIX clone, as another example.

<comment><USER13> Thank you for explaining. I disagree, but then, I started with the Commodore 64 and BASIC, and have missed them ever since. C and LISP version 1 sort of fit in the same space. I hate any language that hides the machine from me. Also don't really like clicky gooey stuff. Text and typing is where it is at. Matter of taste really. But newLISP is a good mix of hardware access with safety.</comment></comment></comment></comment></comment>


Pie Context Menu for web pages - <AUTHOR> https://github.com/cevherkarakoc/Pie-Context-Menu <comment><USER2> If it meets the guidelines, this might make a good "Show HN".

Guidelines for Show HN: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

I've long been partial to pie menus, even if they never caught on. How long? Since reading this article in 1991: [http://www.donhopkins.com/drupal/node/98](http://www.donhopkins.com/drupal/node/98).

<comment><AUTHOR> Firstly thank you .I am newbie on HN and I just found out Show HN.</comment></comment>


12 SQLite Resources for iPhone Developers - <AUTHOR> http://www.mobileorchard.com/iphone-sqlite-tutorials-and-libraries/ <comment><USER2> +1 for SQLitePersistentObjects (<http://code.google.com/p/sqlitepersistentobjects/>).

I'm using it in all of my applications that need SQLite access, and it rocks.

</comment><comment><USER3> I've been using TouchSQL but may convert to the SQLLitePersistentObjects.</comment>


CSS: It was twenty years ago today - <AUTHOR> https://dev.opera.com/articles/css-twenty-years-hakon/ <comment><USER2> > _In my initial CSS implementation in 1995 I used the "SkyBlue" constraint > solver to resolve conflicting style sheet statements. (By the way, "SkyBlue" > and "Cassowary" were both developed at the University of Washington.) Having > a constraint solver allows you to express relationships between arbitrary > elements and have conflicts resolved automagically. However, things can get > complex when elements disappear and new ones arrive, like they do through > DOM operations. Circular dependencies must also be handled gracefully. > Therefore, the idea of allowing CSS to express layout constraints between > any elements were dropped at an early stage._

That was the biggest mistake, IMO. John Nagle's comments here [1] express that point really well:

> _With Dreamweaver 3 and tables, it wasn't necessary to look at HTML to lay > out a page. With Dreamweaver 8 and CSS, the page designer must understand > CSS, HTML, and probably Javascript. That's was a big step backwards. The CSS > system is just too programmer-oriented. And I'm a programmer. (Programmer as > in MSCS from Stanford, the Nagle algorithm in TCP, inventor of ragdoll > technology, real-time robot vehicle control, not programmer as in "writes > some Perl". And my first web site went up in 1995.) It's not that CSS is > hard; it's that CSS is bad._

> _The worst problem with DIV-based layout is that the layout system is too > weak. There's no form of "grid" layout. There's no way to relate a DIV to > anything but its predecessor, its parent, or an absolute position. The > system is just too dumb. That's why people have to stand on their head just > to get three columns to work. Tables actually are a better designed layout > system. Table layouts allow table cells which span multiple rows and > columns. If all tables could do were simple grids of cells, the CSS approach > might make sense, but tables are more general than that._

[1] [http://www.raizlabs.com/graiz/2006/09/25/ten-reasons-why- css...](http://www.raizlabs.com/graiz/2006/09/25/ten-reasons-why-css-sucks/)

<comment><USER3> "Any donkey can kick down a barn, but it takes a skilled carpenter to build one."

What language would be able to support billions of websites coded by millions of developers, rendered on thousands of different types of media and be easier to code with than CSS? Until I've seen a working demo of this mythical styling language, I'll be very grateful for what I've got.

<comment><USER4> Unfortunately in the current climate you're unlikely to see someone even try to develop a competitor to CSS, JavaScript, or HTML.

The problem is that those technologies are all held hostage by at least two inefficient committees, and enough browser vendors have signed on to that to make doing anything without their approval near impossible.

So let's say you had a magical CSS replacement which is perfect in every way, that's ten years in committee which is a back and forward process where they can effectively force you to alter the design for obscure reasons, and then even after that you have to convince every single browser vendor to implement it, and only then FINALLY will it take another ten years for all browsers to support your new syntax so you can use it freely without worrying about incompatibility.

<comment><USER3> Part of the achievement of CSS is precisely that they __have __managed to convince every browser vendor to support it. It has overcome or is strongly competing with Flash, ActiveX, native apps, PDF, and a lot else.

This magical CSS replacement would have to do that, even if CSS didn't exist.

</comment></comment></comment></comment><comment><USER5> I think CSS has become the thing it was supposed to prevent. A modern web page is impossible to render as anything other than a web page; you can't separate the styling from the content, and if anything the complexity of CSS makes doing so harder than in the days of font tags and tables. Users were supposed to be able to override the styles of their pages, but have you ever tried to do that lately? (e.g. I wish I could make all the fixed-width pages on the web full-width).

When CSS is being generated by programs, you might as well have those programs generate inline styles - what would we lose? And we would gain in simplicity.

<comment><USER6> _Users were supposed to be able to override the styles of their pages, but have you ever tried to do that lately?_

That probably has more to do with the "appification" of web sites than anything else, where huge amounts of JS and CSS are used together to produce a poor imitation of a desktop application. Pages that aren't SPAs are far more amenable to styling changes, and are often quite readable (or even more readable) even with all author-CSS disabled.

 _When CSS is being generated by programs, you might as well have those programs generate inline styles - what would we lose? And we would gain in simplicity._

I see inline styles as being more of a "one-off" thing, while CSS selectors can affect many nodes in the tree, so I think both have their uses. The "simplicity" is offset by the increased memory consumption and overhead of parsing every inline style, when much of them will be the same. You could argue that pages could be compressed and maybe browsers could use methods to identify duplicate styles so they can also compress them in-memory, but why do all that (i.e. making every client, on every page reload, have to expend the resources to derive this information) when you can group together common styles under one selector for which the browser will naturally treat as one object?

<comment><USER5> Maybe inline is an extreme example - but suppose we didn't allow the selector syntax, only a simplified form of CSS where the only selector is a single class, and only allowed one class per element? Then the browser could share everything it can share today - it still needs to compute the final style for every element on the page, so the only way it can reuse styling information is if two elements come out with exactly the same style - but it would be much easier to see why any given element was styled the way it was, the browser implementation could be simpler, and our programmatic frameworks for styling components on the page would still be able to help us avoid repeating ourselves.

</comment></comment></comment><comment><USER7> My exact thoughts on CSS are best summed up by this legendary item :

[http://craphound.com/images/css_is_awesome.jpg](http://craphound.com/images/css_is_awesome.jpg)

</comment><comment><USER8> CSS is problematic in every project I've been on. It takes a lot of effort to stay disciplined and not just throw stuff in a class namespace that shouldn't be there. This article [1] by Nicholas Gallagher sums up how I feel after trying my damnedest to write maintainable CSS in my applications. I'm now using the Suit CSS [2] preprocessor to enforce strict guidelines to our app's CSS. It's working well so far.

[1] [http://nicolasgallagher.com/about-html-semantics-front- end-a...](http://nicolasgallagher.com/about-html-semantics-front-end- architecture/)

[2] [http://suitcss.github.io/](http://suitcss.github.io/)

<comment><USER9> Your first paragraph suggests the problem lies within your team and not CSS. I'm sure that's not your intention but that's the way it reads.

<comment><USER8> Yea, definitely didn't mean to sound like that. Edited my original post.

</comment></comment></comment><comment><USER10> "What's your opinion on pre-processors like SASS and LESS? Does CSS have anything to learn from them?

(...) My own favorites would be nested comments, and single-line comments (starting with //). When CSS turns 50 I'll tell you why they were not part of CSS from the beginning."

Now, this makes me really wonder why single-line comments weren't part of the spec from the beginning. And I can't wait 30 years... Anyone an idea?

<comment><AUTHOR> single-line comments are already supported in the way that are invalid css :) so if you comment with // the stuff that follow will be ignored. Again, it is invalid CSS and I am not suggesting that you should use it, just bringing that up :)

I personally like how single-comments works on pre-processors. They are ignored at compile time and therefore are a good way to comment on functions, mixins or anything that won't be compiled to raw CSS.

<comment><USER11> Be careful with using // in CSS. It causes some browsers to completely ignore the _whole rest of the CSS file_ after the line you wanted to comment out (iirc IE9 does this).

When I want to quickly comment something out (and don't have an editor shortcut handy), I just put an 'x' in front of the property name. I.e.:

        xbackground-color: #f0f;

<comment><AUTHOR> Yeah, well anything invalid :)

</comment></comment></comment></comment><comment><USER12> If you haven't seen it, it's worth checking out his PrinceXML browser. It's basically an entire web browser that implements many of the CSS working drafts way before any of the mainstream browsers. It's designed for turning html/css into professional quality PDFs, so it implements a lot of the very early print media related working drafts, e.g. the one for running headers and footers, and the one for generating a table of contents automatically from page numbers. Turning analytics data into PDF reports is something pretty much every big company asks for at some point, and if you're willing to spend the time learning all the w3c specs then it's actually pretty viable.

</comment><comment><USER13> CSS is pretty embarrassing if you ask me. Maybe it was suitable for simple and small document styling for total noobs, ok, but as a standard for web development it's rediculous and sucks all the way... And the worse part? They are still adding to it instead of giving up and leaving it as it is.

We desperately need a better standard, more in the direction of QML, so you can also talk with a lower level language. If you come from a systems programming language and you want to design a UI with CSS, well, good luck! It will suck all the joy out of your work. Center some text or a div? well buckle up for some fine days of f@*$ing around with position: relative; or position: absolute; margin: 0 auto; text-align: center; ? It all depends on the situation, and if one thing changes, your whole design is gone.. ..it's pathetic.

</comment><comment><USER14> Great story. I have yet to think of a valid reason why "box-sizing: border- box" should not be the default. It goes into every CSS document I've ever written.

<comment><USER15> Then you probably haven't been writing CSS for very long. Its support is quite recent. border-box is a much smarter default, but they'd break a lot of old sites by changing the default behavior.

<comment><USER14> Correct, only a year or two.

<comment><USER15> It's funny—back in the day when IE 6's box-model did it more like this (it was really margin-box, which still doesn't exist and probably never will), I used to say that IE's model, _while incorrect_ was superior. And people would disagree with me vehemently. Now, people swear by border-box, which is much more like the old incorrect IE box-model (for good reasons). But it's funny how anti-IE sentiment overruled common sense.

</comment></comment></comment></comment><comment><USER16> I was looking for the following points when reading through this interview:

1\. A mention of the box sizing model ( which is imo the core of CSS )

2\. Following that, a mention of the double margin IE bug. Nope; but there was vague mention of browser differing in spacing.

3\. Mention of the fact that nothing can be changed because browser vendors don't get along and refuse to change stuff in any meaningful time-frame regardless of the specs. Wasn't disappointed.

4\. Mention of SASS/LESS. It's there.

5\. A statement along the lines of "CSS is obviously wonderful because it's still around. It will be around forever." Got it.

6\. Mention of the need for a way to do paging properly. Yay.

Pleasantly surprised by:

1\. Mention of the Acid tests.

2\. Mention that single line comments are desirable. Why still not there???

Unhappy with: Hatred for IE conditional comments, web fonts, and the video tag. ( but confused since he advocated for both web fonts and the video tag?? )

All in all an interesting read.

<comment><USER17> > Unhappy with: Hatred for IE conditional comments, web fonts, and the video > tag. ( but confused since he advocated for both web fonts and the video > tag?? )

The question was "what would you banish? what would you add?"

His response was like:

Banish: Conditional Comments Add (past): web-fonts, video tag Add (future): Pagination.

I was confused as well, and had to read it like 4 times until it made sense.

</comment></comment><comment><USER17> As far as I can tell there are three opinions on CSS:

1) CSS is a single-pass layout programming language. It is impressive, but the single-pass constraint makes certain layouts very difficult to achieve.

2) CSS should be replaced with a constraint solver. Look how powerful Auto- Layout in iOS is. With a constraint solver, you are only limited by your imagination and intelligence, not some single-pass rule.

3) CSS sucks because people think visually in terms of grids and boxes, and it is too hard to do even the simplest thing with a single pass layout language.

I am personally in Camps 1 & 2, but Camp 3 is by far the most vocal. Constraint solvers are powerful, but they require a huge amount of thinking, and you end up with stuff like '==|50[x(30)]<=|==' as the interface.

I think the "flexbox" stuff is pretty good as it is an attempt to accommodate both groups 2 & 3.

</comment><comment><USER18> The CTO's setup:

[http://hakon.wium.lie.usesthis.com](http://hakon.wium.lie.usesthis.com)

</comment><comment><USER9> Somewhat interesting but not very thought provoking. But some of the history of how it came about was nice. After all, he didn't even answer the question about using a magic wand to banish features of CSS. The first two paragraphs are browser features and the third paragraph speaks of adding features.

Which brings up an interesting point to me, even the creator of CSS provides non-CSS complaints when asked what's wrong with CSS. A great deal of the dislike and hate towards CSS seems to be so misplaced.

But I even do the same thing. When asked what I think is wrong with CSS my response is all the designers out there that continue to insist on designing web pages as if they were print designs for a magazine.

</comment><comment><USER19> CSS seems to be one of the worst designs in IT industry, isn't it? See [http://www.zazzle.co.uk/css+is+awesome+mugs](http://www.zazzle.co.uk/css+is+awesome+mugs)

</comment><comment><USER20> It's 2014 and browsers are only now starting to add native support for CSS variables. CSS would be so much easier and cleaner if it supported conditional logic (for layouts) and more powerful variables.

</comment><comment><USER21> I think they should have cloned HTML tables and called it <layout> or something. It's certainly not perfect, but it would have been an easy way to solve a lot of problems.

I know it violates the strict separation of style and content, but how well has _that_ actually worked out?

(This is me just being cranky -- I've done a bunch of typesetting resume's and such when I was younger -- so having tabs work like they used to on old typewriters, where you set them to a defined distance from the left, would have solved a bunch of problems, too.)

</comment><comment><USER22> > I believe that the CSS code we write today will be readable by computers 500 > years from now.

Well, good luck with that one! I wonder if he seriously believe computers in 500 years time will actually resemble our computers in any way? Or was it a throwaway comment? I hope for the sake of his sanity it's the latter!

<comment><USER23> Not sure what you mean. Are you suggesting everything produced today will simply be thrown away? There will be much better computers 500 years from now, but people will still want to see content created in the early days of computers (if only to giggle).

</comment></comment><comment><USER24> Very interesting to learn that what we now call "responsive layouting" was already proposed in the original document. Of course, at the time the proposal was written the original "the user agent has the final say of rendering decisions" philosophy was still going strong, before the years of rigid pixel- size-everything, "requires 1024x768 or more" mentality borrowed from the print world.

Also, I'm glad that the percentage-based weighted-average influence system did not make it into actual CSS :)

<comment><USER25> I don't think rigid pixel-size-everything was a "mentality", so much as a way around the lack of min and max-width we didn't have until CSS2. 100% width websites looked bad.

Rigid made sense. Economical to make and most of your visitors were 800 x 600 and above for many years. Fixed width sites still look and function well on tablets in many cases.

Absolute positioning rocks! I like it's predictability.

Funny that he said he doesn't like conditional comments! "Bad for web standards". Agreed.

</comment></comment><comment><USER26> Notice the proposal date back to when Mosaic Netscape 0.9 was released!

</comment><comment><USER27> I remember printing up the CSS rules, studying them instead of paying attention in class, and then implementing them on my website...

...only to have all the CSS in the <head> get rendered by the popular browsers of the time, and friends tell me that my webpage was broken and that if employers saw I couldn't even make a website I'd never get hired.

Fun times.

</comment><comment><USER28> Who else is having a "bad css day"? Just spent a few hours nailing down font rendering differences across Internet Explorer versions. Ended up using a combination of conditional statements & weird ms-specific media queries. CSS. Fun for the whole family.

<comment><USER29> Is that really a CSS issue?

<comment><USER9> I would say it is not.

</comment></comment></comment><comment><USER30> I've never met anyone who likes CSS. Sure, I write it, the people I meet write it and it's unavoidable but it's little more than a necessary evil, as nothing else works on the web.

</comment><comment><USER31> Is it's birthday really today? I had heard December 17, 1996 which is 17 years ago... ?

</comment><comment><USER32> He's happy with CSS? I'm gonna shoot myself.

<comment><USER33> Regardless of whether you like the technology or not, it's used in virtually every modern computing platform. I'd feel pretty damn good about creating something like that.

<comment><USER34> The guy who created comic sans doesn't agree :)

</comment></comment></comment><comment><USER35> It's a legacy language now. Time to let go.

<comment><USER36> What has replaced it?

<comment><USER37> Nothing, unfortunately. I guess he means it's been around to long and it's based on flawed design principles.

<comment><USER35> Yes, I hate the ceremony. Oh the sacred ancient language that is so standard we can never touch it because Open Web!

</comment></comment></comment></comment><comment><USER38> Ah yes, the beginnings of Opera, when they had a management that was interested in great technology; before it was exchanged for a management interested in profits.

<comment><USER39> Perhaps the alternate universe ending is "before it went bankrupt".

<comment><USER38> Nah, you can look at their financial reports that Opera 12 was still providing good profits on the desktop WHILE they were working on making Chromera 15: [http://www.operasoftware.com/company/investors/finance](http://www.operasoftware.com/company/investors/finance)

Once they were able to fire most of their dev staff though they made more money with the Chrome clone.

</comment></comment></comment><comment><USER40> Sgt. Pepper taught the band to play...

Downvote me, I couldn't help it.

<comment><USER41> Maybe you could read at least the first paragraph of the linked article.

<comment><USER40> Maybe I love The Beatles and can't help completing that immortal verse.

Only THEN, I will read what it's there to be read by one of my myths: Bruce Lawson.</comment></comment></comment>


Remove the safety net: why making a fool of yourself is a good thing - <AUTHOR> http://blog.businessofsoftware.org/2008/05/remove-the-safe.html

<comment><USER2> There is definitely some merit to this approach, however one shouldn't forget the wisdom in Aesop's fable, "The Boy Who Cried Wolf."

If you make enough audacious claims, and fail to live up to them, you lose credibility. People don't just doubt you, they think you're full of it.

<comment><USER3> True, but if you are know to fall only occasionally then you have a definite advantage.

</comment></comment><comment><USER4> It's like what PG says here: <http://paulgraham.com/startupfunding.html>

"Fear of failure is an extraordinarily powerful force. Usually it prevents people from starting things, but once you publish some definite ambition, it switches directions and starts working in your favor."</comment>


What the Industry Knew About Sugar's Health Effects, but Didn't Tell Us - <AUTHOR> https://www.npr.org/sections/thesalt/2017/11/21/565766988/what-the-industry-knew-about-sugars-health-effects-but-didnt-tell-us <comment><USER2> >In the PLOS Biology paper, Glantz and his co-authors argue that the ongoing controversy surrounding sugar in our diets "may be rooted in more than 60 years of food and beverage industry manipulation of science."

This is really frightening.

It is also sad that their is so little education on nutrition. Extremely mind boggling.

All hail obseity, when you can get 10 chicken nuggets for a $1.49, but a grilled chicken salad will set you back $8-$12 bucks.</comment>


Fake News 'Vaccine' Inoculates Against 'Alternative Facts' - <AUTHOR> https://www.psychologytoday.com/blog/the-athletes-way/201701/fake-news-vaccine-inoculates-against-alternative-facts <comment><AUTHOR> direct link to the mentioned study: [http://onlinelibrary.wiley.com/doi/10.1002/gch2.201600008/ab...](http://onlinelibrary.wiley.com/doi/10.1002/gch2.201600008/abstract)

</comment><comment><USER2> Or is this in fact fake news?

<comment><AUTHOR> Or is it.. not?</comment></comment>


Prefab Home Designer Bucks A Downward Trend - <AUTHOR> http://www.npr.org/templates/story/story.php?storyId=99250186

<comment><USER2> I think pre-fab homes is a wonderful idea and wish it would take off more. Imagine if we built cars like we built homes:

1) They'd be hand-assembled by local artisans...

2) ... in your driveway.

3) The median production run would be 1 vehicle.

4) The design would be done from scratch every single time.

5) There would be no Blue Book, because no two cars worth buying are identical. If you want to know what your car is worth, you have to hire an appraiser. His job is to go around the neighborhood looking at all the cars, identify those that are "comparable" to your car, and then see how much they have sold for recently. Then, after having done that, he picks a random number. Stick a dollar sign in front of it and that is what your car is worth.

6) Your new car will need to be exhaustively safety tested, since it has never been built before. Don't worry, your local government has a body whose only job is to promulgate and enforce safety codes for cars built within its jurisdiction. These codes are incompatible with the codes for another car driven a mere six blocks from yours.

7) Economies of scale? Hah!

8) There would be so much uncertainty in selling cars, because so much of them was one-off, that you'd need two _teams_ of overpaid professionals to actually sell one. (One team would include, at a minimum, a broker, a lawyer, and an appraiser.)

9) You might not have the foggiest clue of industrial design, but don't worry, you'll be asked to make all sorts of decisions on the design of your automobile anyway. From "How many cupholders do you want?" to "Here are forty- seven types of available sheet glass -- what do you want your windows made of?"

10) Essentially all the used cars on the markets will have been built as cluelessly as #9 suggests.

11) You would never know the exact price of a car before commissioning it. Car artisans would routinely miss price and delivery targets. They use the excuse that you had no clue what you were doing when you gave them the directions that they asked for, which is true as far as it goes.

<comment><USER3> Many houses today are built in tracts. The designs are standardized and many of the parts are prefabricated in factories. The line between site-built and factory-built housing is blurring. <http://en.wikipedia.org/wiki/Tract_housing>

_Early tract homes were often identical, but more recently built tract homes no longer look identical from the exterior; variations range from mass- produced homes with superficial, cosmetic differences to multiple variations in footprint, roof form, and materials. In addition, floor plans may be reversed or rooms or garage bays added or removed. Builders or buyers of new homes may also be able to specialize custom upgrades._

So, it seems that modern tract homes are made similar to the way cars are: based on standardized designs, but available in various models and with options. From the wiki link above:

 _Components such as roof trusses, plumbing trees, and stair systems are often fabricated in factories and installed on site. This allows contractors to reduce prices, which in turn can make homes more affordable_

Here are some new housing tracts in the Bay Area: <http://www.lennar.com/New- Homes/California/San-Francisco> The prices are locked-in before construction, so the customer will know what he will be expected to pay.

There are also tract homes that have been preconfigured and completed (built) before sale, and have definite prices: [http://www.lennar.com/New- Homes/California/San-Francisco/Pal...](http://www.lennar.com/New- Homes/California/San-Francisco/Palisades-At-Mt-House) Purchasing such a home is analogous to purchasing a new car off of a dealer's lot (instead of ording one shipped from the factory with custom options) - it isn't custom configurable, but it is available right away.

</comment></comment><comment><USER3> These are kit homes. They have to be assembled on a prepared site by a contractor. The kit prices seem reasonable - only about $30-40 per square foot - but the all-in costs are far higher. Here is the information from the FAQ at Romero's website: <http://www.rocioromero.com/LVSeries/faqs.htm>

_On average the home costs $120 sq/ft to build. This includes kit costs, shipping, foundation, and finish costs. This price does not include the cost of land. In the Mid West it can be built between $100-120 sq/ft and in California as well as certain select areas on the East Coast have higher sq. ft. labor costs, the average is between $120-195 sq ft._

The kits do not come with insulation. They have insulatable space in the walls that can be filled with fiberglass batts or spray-on icynene foam.</comment>


Virtual Reality Fails Its Way to Success - <AUTHOR> http://www.nytimes.com/2014/11/16/magazine/virtual-reality-fails-its-way-to-success.html?ref=magazine

<comment><USER2> I think most of us have known "real" VR is inevitable ever since the idea clicked, round about 1990 or so. So far it's lacked the urgency that could have made it a "moon landing"\- level quest. Maybe it lacks a killer app.

I think what Palmer has done is organize a vote, where the verdict was, "Yeah, we want it now. Let us find our own killer apps." Whatever, we now have Carmack, Patron Saint of end-to-end Latency, and Samsung, kind of working together-ish in as concerted an effort as there's ever been to make VR work.

Oculus is bound to seem stone-aged even 15 years out, but it's a strong start.

From the article: one thing that stood out that I haven't thought much about is the potential to use VR to achieve altered states (other than the standard immersion and nausea).

<comment><USER3> I'm starting to think Oculus is becoming a gimmick. It needs success in order to be successful. That's tautology to an extent, but it's really that simple: If it hasn't had any success, it's not successful, and success is nowhere on the horizon.

It's a cool experience, to be sure. And maybe someday it will be mainstream enough where everyone has an Oculus. But that day seems very far in the future.

<comment><USER4> How can it be a gimmick if it hasn't even launched a consumer version yet?

<comment><USER5> You misunderstand, it's a gimmick UNTIL there's a version consumers will buy.

</comment></comment></comment></comment><comment><USER6> I was surprised that I was immediately nauseous within seconds of putting on an Oculus, because I don't feel disorientation watching 3D movies or riding amusement park rides. It was something more deep seated than that, akin to motion sickness or ocean sickness, and I hadn't felt such an immediate onset since I was young.

So I'm thinking that the component that's missing is not so much better hardware, but a sense of control, because right now we are along for the ride but we want to be driving. The big off-putting things for me were:

* Screen door mesh appearance of seeing the mask area around pixels (which arguably shouldn't be present on an OLED)

* Difficulty getting the focal point and field of view right (because really this is just a cell phone and some reading glasses, see Google Cardboard)

* Incorrect or missing association between gravitational up and simulation up (inner ear confusion)

* Not seeing my own body in the scene (needs integration with Xbox Kinect)

* Possible lag because the Rift may not be using movement prediction/dead reckoning (though I didn't notice any, so maybe it is)

Really these are quite minor and easy to fix compared to what's been accomplished so far. The only real expense is eventually going to be an affordable 4x HD display, because webcams for the optical tracking, gyros, tracking software and 3D drivers are all trivial or open source. Someday the controller will be a $5 chip like USB and work with any HDMI display.

Also the fact that the split screen projection works with ordinary video is causing all of this to go viral.

I'm trying to wrap my head around how stereoscopic panoramic video recording will work, because that's the last thing stopping VR (not hardware).

I'm thinking the best way to solve that will be to scan a moving 3D panoramic scene into a computer and use the difference between frames to infer distance to each pixel. I'm having trouble finding a link, the closest thing I could find was the 2005 ShoWest where they talked about remastering a 2D movie like Star Wars episode IV into 3D at 48 fps:

[http://www.davidbordwell.net/blog/category/directors- cameron...](http://www.davidbordwell.net/blog/category/directors-cameron/)

[http://www.davidbordwell.net/blog/wp- content/uploads/3d_dire...](http://www.davidbordwell.net/blog/wp- content/uploads/3d_directors-400.jpg)

Some other ideas might be to also use a laser rangefinder or ultrasound, light fields or split the image coming through the sphere with a partially reflective mirror onto two or more CCDs and have the computer infer the distance to each pixel by the correlation between the images. Anyone know any research/projects that explore recording panoramic 3D video?

</comment><comment><USER4> VR didn't take off until now because the right convergence of other technologies hadn't been reached yet. The smart phone explosion lead to cheap, high resolution displays, much like the popularity of the Wii brought the price of gyroscopic sensors down. Graphics hardware also became powerful enough to render scenes twice and reverse the fisheye effect of the cheap lenses used in the Oculus, which in my opinion was the real light bulb moment for the project. The value and application of VR has been obvious for decades, but the previous attempts were hampered by some serious technological limitations.

</comment><comment><USER7> That seems like a weird statement by Cameron if it's true. When did he say that? I would expect that someone like him would still have nice things to say even if the technology was still a little off-the-mark (whether or not the Rift is or isn't off-the-mark).

</comment><comment><USER8> A friend told me the other day that only "static" scenes really work, where you stay in one place. And when the player starts to "move around" the lag causes nauseousness. Is this true?

<comment><USER9> I won't speak for anyone else but I've had a Rift dev kit for the past several months and what I've found tends to confirm a lot of my expectations: in applications where your viewpoint matches your physical viewpoint (seated in a chair or walking around a small area that stays in one place while also walking in real life) nausea is pretty much not an issue when there aren't other issues with performance (like if you hardware can't keep up with what you're asking it to render, it will "stutter" as the framerate drops but that's more headache-inducing).

Software like Elite: Dangerous or the tech demo "Sightline: The Chair" work great because your "avatar" is in the same seated position as you are. Once you try to shoehorn VR into a more traditional first-person video game style setup, it gets dodgier. Since you don't have the range necessary to actually walk around that far, people tend to use things like gamepads or the traditional WASD/mouse controls to move around. This can really throw you off because in a game, the mouse or analog stick controls your facing direction but in VR, so does your head. At the same time, in real life, you can face your body in one way and still move your head independently. In VR, it can take some practice to be able to "get" that without feeling nausea. Any time your actual head's motions aren't 1:1 with the view on screen it can get questionable. The closest thing I can think of is the feeling of "the spins" if you've ever had too much to drink and try to lay down. The seeming disconnect between head motion and viewpoint motion throws your balance for a loop.

Then there's the whole forward-backward-left-right thing. If you're sitting in a chair but your on-screen body is running around or jumping or falling your inner ear is telling your brain a different story than your eyes are.

Honestly, this is why I have my issues with some projects and users that feel a traditional FPS-game experience is the holy grail of VR. I can see how it would seem that way at first glance because how much more first person can you get? Still, experiences like Elite or The Chair or even a game like Couch Knights where you're looking around at a virtual "game board" while your surroundings stay in place really do create an amazing sense of immersion and presence.

I think that while gaming will be the early focus due to the existing graphics engines and the fact that many gamers are used to buying high end computers and pricey peripherals, the real innovations will come with the projects that are just now getting started. Stuff like using depth cameras to recreate a 3d "movie" you can look around in or transmitting similar information over networks for 3d telepresence is going to be a much more mainstream and transformative development than playing the vidya games in VR.

The article touched on a point that I'm always reminded of. Those old devices like the Apple Newton or even the more popular successors like the Treos and the PocketPCs were awesome and promising but the smartphone market didn't really take off for several more years because the hardware and software needed to make them polished, fast, and ergonomic didn't exist yet. The Rift is like my old Treo but someday the tech will exist to deliver something more akin to a modern smartphone at equally (relatively) affordable prices for average people.

<comment><USER10> The "Elite: Dangerous" example is interesting. What's the difference between flying around in space and flying around a typical FPS game? I don't have personal experience with the Rift but here are some thoughts:

\- The "context" of the cockpit is helpful in some way, it's an environment which "agrees" with your inner-ear sense. If the cockpit were removed from Elite, would "presence" be lost? If a cockpit of some kind were added to a typical FPS game, would that decrease the dissociated-motion effect?

\- Movement is different in Elite. The environment that disagrees with your inner-ear (space and the things in it) is far away, moves more smoothly than a typical FPS, and is sparse. This probably makes it easier to accept than the fast, jerky movement inside small, constrained environments of a typical FPS.

</comment></comment></comment><comment><USER11> Hey, at least the article mentions Artaud. His work has always seemed like the secret weapon for good VR work to me.</comment>


Functional Programming with Python - <AUTHOR> http://kachayev.github.io/talks/uapycon2012/index.html#/ <comment><USER2> So I felt really torn with this. I applaud the author for introducing Python devs to FP; I love functional programming. Python was one of the things that opened my eyes to FP with its cute little m/r syntax and for that I'm forever grateful.

Over the years, I have found that python code that people write to solve problems will fall in roughly four categories: a) completely ignorant and inefficient code; b) concise, idiomatic python code with a focus on readability; c) fancy functional code where the author is showing off their FP savvy (peppered with recursion and m/r); and d) raw, boring C-influenced code that looks primitive and boring to read, but is incredibly efficient and algorithmically sound. As much as I used to love going for b), I then prided myself for writing c). But last few years I have realized how under performing c) is for most serious work, so I tend to avoid it and try to strike a balance between d) and b), but preferably the latter. To write code in c) and tell yourself, well the data size will never be so great that the stack will blow, or memory will suffer, is in many ways just like avoiding null checks all together and saying to yourself your data will always have perfect integrity... e.g. any sane person will tell you that you cannot rely on this mindset in the long run.

So, for me at least it comes down to this: to try to pretend that you can write FP code effectively in Python is an exercise in futility. FP is more than writing a map and reduce. If thats your basis of reasoning, yeah I agree take that and run with it - I find m/r to be a neat syntax to use here and there in your program but its really challenging to write a whole program in python that is composed of several chained map / reduce functions to a large extent because things are not oriented around generators by default.. I'm not saying its impossible, just that it goes against the grain. I also argue that recursion and guard expressions (and lazy evaluation) are at the heart of the FP paradigm and if you want to do it right, then its just retarded to sit and do this in Python when there is no tail recursion.. how are you going to appreciate this concept when its so limiting?? If you want to muse yourself and marvel at pretty code, write it like this and have fun with it, but please pick another language if you want to actually ship production code.

And ... so sorry to piss on the parade.

<comment><USER3> Yeah, i gave up on doing fp (or any mathematics) in python when I got surprised by this:

>>> monomials = [lambda x: x(star)(star)i for i in [1,2,3]] #(not sure how to escape stars for exponentiation properly, whatever)

Those all end up being the _same_ monomial because the integer i is captured _by address_ and not given a new binding for every iteration. Very surprising, and an accident waiting to happen for anyone used to dealing with integers by value (hard to say that with a straight face).

The hackish workaround is "lambda x,i=i: x(star)(star)i" but I'd forget it all the time.

<comment><USER4> This is just like how python default values are global variables that if you modify over time (ie, def foo(x = []): x.append(0), the second iteration x would be [0,0], because it is only initialized once.

<comment><USER5> Not global. Scoped with the "def".

<comment><USER6> I think zanny meant "static" rather than "global".

</comment></comment></comment></comment></comment><comment><USER7> Look, I love functional programming. I use it all the time and I procrastinate in the shower about the best to add currying to all my favorite languages. That being said, even after all those years, I still find this:

        expr, res = "28+32+++32++39", 0
        for t in expr.split("+"):
            if t != "":
                res += int(t)

        print res

SO MUCH more readable than this:

        from operator import add
        expr = "28+32+++32++39"
        print reduce(add, map(int, filter(bool, expr.split("+"))))

A couple years ago I created a library called Moka in python to make functional and nesting easier. That would be written this way:

        (Moka(expr)
           .do(string.split, '+')
           .keep(lambda x: x != "")
           .map(int)
           .reduce(moka.add))

Still, the imperative version, althought it has state and feels hacky for a functional hacker, is still pretty damn clear and easy to read.

<comment><USER8>
        expr = '28+32+++32++39'
        print sum(int(i) for i in expr.split('+') if i is not '')

<comment><USER9> It's really weird to me that the author prefers map(add, ...) to sum(generator expression).

<comment><USER10> Because with map you can use any function and sum maps __add__. It also illustrates passing functions as arguments.

More subtly, a generator (or list comprehension) implies the order in which the results are generated and an implicit but observable changing state. If I'm trying to write (or, at least, express, since we are talking about Python) parallelism, map would be a better choice.

<comment><USER11> _More subtly, a generator (or list comprehension) implies the order in which the results are generated and an implicit but observable changing state. If I 'm trying to write (or, at least, express, since we are talking about Python) parallelism, map would be a better choice._

This is definitely not true -- generator expressions can be expressed using lazy list semantics. By your logic every Haskell list comprehension would be stateful.

I would encourage you to write the denotational or operational semantics of your expressions in these matters rather than simply going by intuition.

<comment><USER10> > generator expressions can be expressed using lazy list semantics

That does not change the fact the results are given in a certain order. Lazy list semantics means the data will be calculated as it's needed, therefore, the calculation cannot be parallelized.

<comment><USER11> Not true.

See [http://hackage.haskell.org/packages/archive/parallel/220.127.116.11...](http://hackage.haskell.org/packages/archive/parallel/184.108.40.206/doc/html/Control- Parallel-Strategies.html#v:parList)

<comment><USER10> I was talking about Python. A list comprehension is defined as having the behavior of a loop.

<comment><USER11> Once again, that doesn't semantically make a difference, unless the loop is side-effecting. However, even without side effects, Python cannot necessarily make any kind of guarantee about such computations since arrays are mutable and can be modified out from under the map.

This is why parmap equivalents take iterables in Python, not arrays. It doesn't matter if you have lazy or eager semantics, only if your semantics are side-effecting.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> The missing slide: profiling.

I love functional programming. Nonetheless, I strongly believe in using the natural idioms of your language: they are more widely used, more widely optimized, and more often thought about.

I think you would find that the functional style is _not_ idiomatic in Python most of the time. This can hurt readability, performance, and interoperability.

Overall, I would encourage people to do what is _natural_ \-- it is often also what's correct. For example, Python generators expressions are lazy sequence semantic constructions and are both functional in semantics and _better_ than the equivalent map/reduce semantics.

<comment><USER12> Good points. Python lists are surprisingly slightly faster than tuples (which are immutable). That's because lists are extremely common, and more effort went into optimizing them.

</comment></comment><comment><USER13> So, basically, with lots of work, you can make something that's technically functional but with none of the beauty of a language that's meant for it.

I understand the appeal of functional programming, really I do, but why can't we accept that sometimes just because you can doesn't mean you should?

</comment><comment><USER14> I used to dream about FP and Python; then I read about Guido's plans for removing `lambda` and `reduce` ([http://www.artima.com/weblogs/viewpost.jsp?thread=98196](http://www.artima.com/weblogs/viewpost.jsp?thread=98196)) and that is when I stopped writing Python.

<comment><USER15> That disappointed me also, but the FP voice from the community is strong enough. Reduce lives on in functools and the functional package also adds additional functions, like compose. It's one of the packages I install first in a new Python installation. But true, Python will never grow into Haskell.

<comment><USER16> Also, lambda doesn't appear to be going anywhere. It's one of my favorite features.

<comment><USER15> Yes, not going away but not growing beyond the crippled, single-statement version it is now...

</comment></comment></comment></comment><comment><USER17> There's little reason to use python instead of haskell these days.

\- compiled code, fast

\- cleaner, nicer, conciser syntax

\- type safety built in

\- pattern matching

\- numpy equivalents are now available

\- purity (see John Carmack talking about how it helps when codebases get large)

To switch from python to haskell easily within minutes, realize that a python function is simply do notation in haskell. So replace assignment (=) with arrow (<-) and write with "func v1 v2 = do".

Then pure functions are those without do and no assignment written lisp/scheme style. "$" means you can get rid of the parentheses.

After that, declaring types is equivalent to expressing how syntax tree can be written. You can use these to plan out how you attack your problem and then let compiler help you when writing out your functions. You could even just write out types and outsource the function writing to someone else (similar to your oo architects can parcel out code writing).

So, all python, golang, and ruby programmers - you really should check out haskell and realize it's superiority. They've taken your niche.

(If anyone wants to pay me to code in haskell, send me an email at firstname.lastname@example.com, looking for telecommute work)

<comment><USER18> It's a completely different language with different goals. It's like you said "there's little reason to eat eggs instead of drinking wine these days." Python was expressly NOT intended to be a compiled language with heavy emphasis on type safety.

</comment></comment><comment><USER6> If you're forced to write Python and you like FP I think it makes sense to try to twist the Python you write towards FP as much as possible. The advice "Stop writing classes" is particularly helpful in my experience.

However the "What did we miss?" slide tells it like it is. FP in Python is never going to be like FP in, e.g., Haskell. Moreover, the libraries you use are going to have objects and mutable state everywhere which ends up being very frustrating.

If you're not forced not to use FP, I recommend just going with Haskell (or OCaml or Scala or whatever according to your taste).

<comment><USER19> _I recommend just going with..._

If you're writing some kind of server, I'd nominate Erlang for serious consideration. The OTP framework is fantastic and rock solid.

</comment></comment><comment><USER20> Great deck about functional programming in Python. Also:

* `operator.attrgetter`, `getattr()`, `setattr()`, `object.__getattribute__` [1][2]

* `operator.itemgetter`, `object.__getitem__` [3][4]

* `collections.abc` [5][6]

[1] [http://docs.python.org/2/library/operator.html#operator.attr...](http://docs.python.org/2/library/operator.html#operator.attrgetter)

[2] [http://docs.python.org/2/reference/datamodel.html#object.__g...](http://docs.python.org/2/reference/datamodel.html#object.__getattribute__)

[3] [http://docs.python.org/2/library/operator.html#operator.item...](http://docs.python.org/2/library/operator.html#operator.itemgetter)

[4] [http://docs.python.org/2/reference/datamodel.html?#object.__...](http://docs.python.org/2/reference/datamodel.html?#object.__getitem__)

[5] [http://docs.python.org/2/library/collections.html#collection...](http://docs.python.org/2/library/collections.html#collections- abstract-base-classes)

[6] [http://docs.python.org/3/library/collections.abc.html](http://docs.python.org/3/library/collections.abc.html)

</comment><comment><USER21> everytime I see

        reduce(operator.add, ...)

and variations like that I think GvR was right to relegate reduce to the functools module... it's just that

        sum(...)

covers the most common (90%? only?) usage...

<comment><USER8> Not just that. More generally, comprehensions cover the most common use cases and are tremendously more readable.

<comment><USER6> Comprehesions are more readable in the sense that they read more like "English" or "natural language". Unfortunately they're inherently non- composable and make refactoring harder.

d0m's Moka example ([https://news.ycombinator.com/item?id=6150944](https://news.ycombinator.com/item?id=6150944)) is closer to composable. I would suggest the following modification. Instead of chaining methods, have a function "chain" which composes functions. We could then write

        chain(do(string.split, '+'),
              keep(lambda x: x != ""),
              map(int),
              reduce(moka.add))

If I decided that removing blanks and converting to int was a concept that was worth capturing in its own function, all that I need to do is splice out part of the chain as is.

        non_blanks_to_int = chain(keep(lambda x: x != ""),
                                  map(int))

        chain(do(string.split, '+'),
              non_blanks_to_int,
              reduce(moka.add))

No modifications were required. It's more complicated with comprehensions. Of course it's still _possible_ , but it's one more unneccessary grain of sand in the mechanism. Doing the same with the imperative version would be nigh-on impossible.

Come to my FP days talk in Cambridge, UK, Thursday 24th October, 2013 if you want to hear more about this!

[http://lanyrd.com/2013/fpdays/sckzkz/](http://lanyrd.com/2013/fpdays/sckzkz/)

<comment><USER22> If you take the awful step of naming things, comprehensions are easy enough to chain. That is (in untested python...)

        parts=s.split('+')
        keep=(s for s in parts if s)
        ints=(int(s) for s in keep)
        sum(ints)

Hiding the middle steps there in a function is easy enough.

That split returns a list, but the other steps are lazy.

<comment><USER6> But naming your intermediate variables means it's not possible to splice parts out.

<comment><USER22> You did call it a grain of sand, but I suppose I'm responding to where you call it complicated. Moving a couple of the names into a separate function means passing in one of them and editing the last line (at least in python with explicit returns). That meets the meaning of more complicated, but (in my opinion) in a sort of hair splitting way.

<comment><USER6> Horses for courses then I guess. If the "easier to refactor" argument doesn't convince you maybe the "easier to read" argument will. Personally I strongly prefer zero-length variable names, but everyone has their own taste.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> I'm a python-native programmer who just recently picked up SICP. I've been trying to use some more functional tools; I told a friend at work one day that I was going to try to do everything with just map and filter.

But I also just had an experience I haven't had much since I was extremely new: the experience of going back to something I wrote last week and not being able to decipher it. I'm going to keep it up, partly because I like it and also because I have some hope (unjustified?) that map will give me better performance than looping. I wish there was a way to enable tail recursion though--seriously, I promise I'll ask for clear stack traces when I need them.

<comment><USER24> @dorolow, your comment is dead because it used the auto-banned word "mast?rb?tion" (uncensored). FYI.

<comment><USER25> What? We've got auto-banned words?

<comment><USER24> Try it and see.

</comment></comment></comment></comment><comment><USER26> Love the video mentioned in the slides:

[https://www.youtube.com/watch?v=o9pEzgHorH0](https://www.youtube.com/watch?v=o9pEzgHorH0)

</comment><comment><USER27> Great presentation! Just a question/remark: Partial function application seems handy but using functools.partial to create a new function seems obsolete since you can use non-keyworded variable length argument lists with *args in your function definitions?

</comment><comment><USER28> The official Python docs also have a section on FP.

[http://docs.python.org/dev/howto/functional.html](http://docs.python.org/dev/howto/functional.html)

</comment><comment><USER29> wow, i love your presentation design, type and function :)

<comment><USER20> is this a reveal.js rendering of an IPython notebook ?

        ipython nbconvert --to slides <notebook.ipynb>

[http://ipython.org/ipython- doc/dev/interactive/nbconvert.htm...](http://ipython.org/ipython- doc/dev/interactive/nbconvert.html#converting-notebooks-to-other-formats)

</comment></comment><comment><USER30> this code is so smart, maybe because it is Python after all

        from operator import add
        expr = "28+32+++32++39"
        print reduce(add, map(int, filter(bool, expr.split("+"))))

but in JavaScript it looks much more readable:

      "28+32+++32++39".split(/([\+]+)/g).reduce((r,v) => r+v, 0);</comment>


You give us a code snippet, we find every site it appears on. - <AUTHOR> https://search.nerdydata.com/leads

<comment><USER2> The pricing here is ridiculous[1]. I honestly can't understand who the target market is here. What does NerdyData offer that I'm not going to be able to solve with something like Oloh or Github code search? What need does the product fill that's going to be worth $100+/month to me? I mean, I get things like "search for a specific GA account number" or "see how many websites use Twitter's embeds", but how does that contribute to my bottom line in a way that validates my paying for it?

I get the sense that there's a useful product here, but it feels like it's being marketed as a replacement for Google Code Search or something, which feels like the completely wrong tack. Selling it as a competitive intelligence tool might be easier to grok, but then why pitch it at developers?

[1] [https://search.nerdydata.com/#!/pricing](https://search.nerdydata.com/#!/pricing)

<comment><USER3> I imagine they're planning on a pivot to Lifelock-like protection.

</comment></comment><comment><USER4> If I know who my competitors _are_ , specifically, how hard is it to find their sites and view source (assuming I didn't set up shop copying their site and business model to begin with)? Chances are anything you can see on their frontend isn't what's giving them a competitive edge. I can't help but think that most of what's offered here isn't _that_ difficult to come by.</comment>


Show HN: Breach Insider – Find out about your data breach, before everyone else - <AUTHOR> https://breachinsider.com <comment><AUTHOR> Some of you may remember the previous discussion about BreachCanary (now Breach Insider) from the DocuSign breach: [https://news.ycombinator.com/item?id=14347188](https://news.ycombinator.com/item?id=14347188)</comment>


Which tech stock would you invest 10k in? - <AUTHOR> With twitter and snapchat on the rise(and the recent market correction). I was wondering what company hackers would invest 10k in.. <comment><USER2> If given the chance, I believe I'd diversify the money. Depending on my intentions (e.g. more interest in high outcome vs more interest in supporting technology) I'd go for a middle way. Today I'd buy GOOG and TSLA. If possible at the time I'd also invest in SpaceX because I really like their efforts. TSLA is more of a I-believe-in-this-tech thing while GOOG ist both the believe in their tech (especially since Alphabet owns SpaceX in part) and the desire to earn something out of the investment. Depending on my own financial needs I would go an split exactly in half or not.</comment>


Automating Complex 3D Modeling - <AUTHOR> https://share-ng.sandia.gov/news/resources/news_releases/3d_modeling/ <comment><USER2> More clealy: "the first provably correct algorithm for conforming Voronoi meshing for non-convex and possibly non-manifold domains with guarantees on the quality of both surface and volume elements"

[https://arxiv.org/abs/1902.08767](https://arxiv.org/abs/1902.08767)

</comment><comment><USER3> It looks to me like this is not automated 3D modeling. Instead it's an improved algorithm for reducing an existing 3D model to a mesh suitable for eg. finite element method simulations.

<comment><USER4> I agree. A process that typically requires manual intervention and tweaking of the source CAD model to arrive at something ready for simulation. As a design engineer maybe I'm not out of a job just yet.

<comment><AUTHOR> Maybe time to start upskilling if a major part of your day to day work is being targeted by AI and algorithms?

<comment><USER5> This is specifically an improvement to meshing, a method used to simplify the solid model of a mechanical design for simulation. It's (generally) a pretty small percentage of our workload. This press release looks like something that will amount to a software update to my CAD program.

</comment></comment></comment></comment><comment><USER6> this isn't first of its kind, most/all cfd/fea packages come with a meshing tool. And most of them are already "one-click" solutions for a halfway decent mesh even on complex topologies with some even doing error handling for the user.

<comment><USER7> That is typically tetrahedral meshing. Hex meshing is sometimes an option, with the caveat that the user must first decompose the geometry (slice it up) into simpler sections that are mappable.

This seems to be automated polyhedral meshing. Which is interesting, but I imagine has limited applicability as most finite element software (that I'm aware of) relies on tet/hex element formulations. Maybe with this advance in meshing that will change, though.

</comment></comment><comment><USER8> I have not so far heard any compelling arguments for using other than tetrahedral or hexahedral meshes in finite element computations. I know that there is a lot of research going on but the motivation is not clear to me.

Error estimates are dependent on the polynomial degree and the average cell size, and not the "amount of corners per cell" or anything like that.

<comment><USER9> The assertion is that computation of phenomena like flow and radiation could result in fundamentally more accurate computations. Minor variations in surface shape and texture can have a large impact on physical interactions. Getting the geometry right could make a big difference. Given that this is a rigorous attempts to advance the state of the art it should be possible to demonstrate this improvement with computations, but with the current state of this project any experimental exercises will have to wait until after SIGGRAPH or whenever this is released as usable software. It seems unlikely that anyone will try to jump ahead of this project using what they have published so far. It seems kind of sad that this work is being advanced first as hype for a licensing opportunity and as research that others could work with second, especially given that national labs are doing this work with public money.

</comment></comment><comment><USER10> Meshing may be on the way out:

[https://www.altair.com/simsolid/](https://www.altair.com/simsolid/)

<comment><USER11> That's not how I read that product page. They claim that the user does not need to simplify the model before inputting it to their modeling domain. Not that they would have invented a completely new method of defining non-convex 3d solid volumes.

</comment></comment><comment><USER12> Even with advanced tools, all I can ever see when needing to clean up complicated models is hundreds of hours of effort.</comment>