The BlackBerry PlayBook Doesn't Exist - <AUTHOR> http://www.singularityhacker.com/ <comment><USER3> When you're the one who's first to market with a game-changing device, you announce it as close to ship date as possible.

Everyone else announces their me-too products as early as possible to show they're in the game. It's been like that for years now. There are few exceptions.

All RIM announced was a roadmap, but it's an interesting one because it includes an entirely new OS and tablet platform that will eventually become the platform for all of their future mobile devices (barring any software engineering disasters). To me, that's a lot more interesting that all these manufactures who rush to market with their 7" Android 2.2 phones and call them "tablets" merely to cash in on the craze.

<comment><USER4> QNX is not a new platform, it's older than Android and iOS combined. Its use as a specialized tablet / mobile OS is new though.

<comment><USER5> Also, I don't think QNX is the platform. For them QNX is the OS layer. But not the platform that you develop against. This is why the dev options are HTML5 and Flash. I bet the third API will be Java based. Like we are used to from RIM.

</comment></comment></comment><comment><USER6> The iPad was released 3 months after it was announced. The Playbook, just announced, is not scheduled to ship until 2011 sometime. So it's clear that RIM is not at the same production level Apple was when they announced the iPad. This is likely why no one was allowed to play with it (it's not done yet).

<comment><USER7> I up-voted you, but I don't believe the author is making a claim any different than your own. The title may be hyperbole, but the point is that _RIM shouldn't announce a device if it isn't done_. As many others have noted in previous threads of this discussion, RIM seems desperate, and they (along with the customers they are clearly trying to keep from adopting iPads) have a good deal to lose if the final version doesn't live up to the hype based on such limited details.

<comment><USER8> I wonder how many corporate IT departments are starting to look at iPad a bit too close for RIM's comfort. Time to drop a little FUD into the mix.

<comment><USER9> Corporate IT? Hell, most managers have already gone out and bought themselves one.

<comment><USER10> Managers are one thing, getting everyone in the company is the next step, and a lot larger number of orders.

<comment><USER11> Apple's Enterprise Management tools are headed into this space.

RIM + Microsoft should be very concerned about Apple as much as Android based devices.

</comment></comment></comment></comment></comment></comment><comment><USER12> It should be noted that they announced it at DevCon. Apart from keeping investors happy, the idea was to let the developers know that such a product is coming and to let them know the tools that they can use to develop for it. Its only slightly different from the WP7 announcement. I believe RIM is releasing (or has released) the SDK. The SDK definitely needed to be announced and provided to developers 5-6 months before product hits shelves so I dont see why other people have a problem with it.

</comment><comment><USER13> It doesn't exist to me either without knowing: (1) the Price, and (2) the projected Battery Life

</comment><comment><USER14> This is the actual URL of the article.

[http://www.singularityhacker.com/2010/09/blackberry- playbook...](http://www.singularityhacker.com/2010/09/blackberry-playbook- doesnt-exist.html)

</comment><comment><USER15> "great artists ship"

I was having a hard time grasping the fact that they have three problems to manage (OS-wise): evangelizing BB 6.0 (for torch sales), keeping older versions of BlackBerry OS, and now Declaring that the QNX-based OS is the future.

<comment><USER16> People keep using the expression "great artists" to refer to a company that makes an out-of-date phone that's only popular because Enterprises can turn the camera off and force users to have a 1 million character password that they have to type before every operation.

RIM is not a "great artist". RIM merely does exactly what people with a lot of money tell them to do, and then they charge the people with a lot of money a lot of money. Then they make a lot of money. It's not art. It's business.

<comment><USER15> what? I wasn't saying RIM is a "great artist" at all, they're terrible. The quote is supposedly from steve jobs.

While I'm writing, my opinion is that the big problem with RIM's tablet is that they didn't think at all about designing hardware that met the enterprises needs, or as you say "people with a lot of money". If they did, they would have made a tablet great at capturing employees thoughts and ideas. My opinion is that this requires two things:

      1) A tablet that handles multitouch AND pen input very well (i.e. get n-trig / wacom hardware/licensing for the touchscreen)
      2) A tablet that doesn't have a small 7 inch screen. The screen size equivalent to a stenographer's book is 10 inches. It's great for writing down lists of things down.

</comment></comment></comment><comment><USER17> RIM used to be creative, BlackBerry devices used to be a game-changer - <USER2> did all that innovative thinking go? I like Apple products, but hate to see every other company just following what Apple is doing and not coming up with their own WOW concepts. I mean, the future of mobile devices can't be just the tablets, aren't there any other possibilities?

Sorry BlackBerry fans, I can't help but feel distasteful of the PlayBook.

</comment><comment><USER18> The author is wrong. Why so serious? It was nothing more than a tease to excite the platform developers. Proper announcement/demo will happen at an appropriate time.

\- Attended the keynote + currently working at RIM as an intern

<comment><USER19> So have you touched the PlayBook yet? Is the OS actually at that level as of this moment? At least that's what you're implying there by saying you're interning at RIM.

</comment></comment><comment><USER20> Having played with a Torch... yes, that ad is simulated imagery. Yes, the actual Torch isn't quite as snappy as the ad. But, its almost as snappy as the ad. As in, if you really weren't paying attention, you wouldn't notice. This isn't like the N97 debacle.

Granted, Storm sucks. Everyone I know working at RIM admits it. But the Torch is definitely a solid device, with a solid touch interface.

I can't speak to the rest. I would like to think that companies showing simulated demos would be truthful in their simulations. In my heart, I really want RIM to be that type of company (their campus is right next to my school). And I think that by and large, they are.

That said, there's a long tradition of BlackBerry prototypes being leaked looong before any type of announcement. The Torch (and the clam shell) in some form of the other has been floating around for nearly a year before they were announced.

<comment><USER8> I was kind of believing the video until that scene where the guy is taking a picture and rotates the tablet... _and the picture rotates, antialiased, in real time_.

</comment></comment><comment><AUTHOR> This story just got picked up by Daring Fireball and ZDNet.

[http://daringfireball.net/linked/2010/09/30/blackberry- playb...](http://daringfireball.net/linked/2010/09/30/blackberry-playbook)

[http://www.zdnet.com/blog/btl/blackberry-playbook-ill- believ...](http://www.zdnet.com/blog/btl/blackberry-playbook-ill-believe-it- when-i-see-it/39868)</comment>


The Next IPhone Could Have A Radiation Absorber - <AUTHOR> http://www.maindevice.com/2012/05/28/next-iphone-radiation-absorber/

<comment><USER2> Maybe they're going to make an atomic powered iPhone with unlimited battery life?

For example, like this: <http://en.wikipedia.org/wiki/Betavoltaics>

</comment><comment><USER3> Is there any evidence that mobile phone radiation has an effect on health? The article seems to assume it's true, but as far as I know, there's no evidence to support that theory.

</comment><comment><USER4> Could the radiation absorber also be used to enhance battery life? I imagine it would be possible to extract SOME kind of power, but i'm not sure how much.</comment>


University President Becomes an Uber Driver - <AUTHOR> https://myownstormypetrelwords.wordpress.com/2015/07/02/uber-from-the-drivers-seat/

<comment><AUTHOR> Check out the subsequent posts as well. The Washington Post also picked it up: [https://www.washingtonpost.com/posteverything/wp/2015/07/29/...](https://www.washingtonpost.com/posteverything/wp/2015/07/29/i-run- a-university-im-also-an-uber-driver/)</comment>


HUD Tenant: software vs. homeless in IOS - <AUTHOR> https://itunes.apple.com/sr/app/hud-tenant/id533650377?mt=8

<comment><USER2> I can see the app in Apple Store but is the app in Android Google Play too?

<comment><AUTHOR> Yes, there is an app for android too, here is the link for HUD Tenant Application for android. [https://play.google.com/store/apps/details?id=com.jedutils.t...](https://play.google.com/store/apps/details?id=com.jedutils.tenant&hl=en)

<comment><AUTHOR> It allows you to search for contact information(phone, email, web site if available) for every Housing Authority in America.

It also provides information about 2014 Fair Market Rent per state/county.</comment></comment></comment>


Handles are the better pointers - <AUTHOR> https://floooh.github.io/2018/06/17/handles-vs-pointers.html <comment><USER2> A few years ago I wanted to make a shoot-em-up game using C# and XNA I could play with my kids on an Xbox. It worked fine except for slight pauses for GC every once in a while which ruined the experience.

The best solution I found was to get rid of objects and allocation entirely and instead store the state of the game in per-type tables like in this article.

Then I realized that I didn't need per-type tables at all, and if I used what amounted to a union of all types I could store all the game state in a single table, excluding graphical data and textures.

Next I realized that since most objects had properties like position and velocity, I could update those with a single method by iterating through the table.

That led to each "object" being a collection of various properties acted on by independent methods which were things like gravity and collision detection. I could specify that a particular game entity was subject to gravity or not, etc.

The resulting performance was fantastic and I found I could have many thousands of on-screen objects at the time with no hiccups. The design also made it really easy to save and replay game state; just save or serialize the single state table and input for each frame.

The final optimization would have been to write a language that would define game entities in terms of the game components they were subject to and automatically generate the single class that was union of all possible types and would be a "row" in the table. I didn't get around to that because it just wasn't necessary for the simple game I made.

I was inspired to do this from various articles about "component based game design" published at the time that were variations on this technique, and the common thread was that a hierarchical OO structure ended up adding a lot of unneeded complexity for games that hindered flexibility as requirements changed or different behaviors for in-game entities were added.

Edit: This is a good article on the approach. [http://cowboyprogramming.com/2007/01/05/evolve-your- heirachy...](http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/)

<comment><USER3> The general approach described by the author is the one used by many game enginges. The main reason, however, the refactor that you've described here isnt used is that it bloats memory by a significant factor (which thereby reduces performance). Since you have to allocate for each array index the size of the largest item in the union, there is a lot of wasted space when you have lots of smaller items. If you have fewer than a couple billion points, a triangle will fit in 12 bytes, a game object can easily have 10 fields for a total of 30 bytes. Thats a massive expansion of your triangle array which will result in more cache misses.

<comment><USER2> Of course, this isn't a general solution to every problem and I wouldn't use it if there was a huge distribution in entity sizes like you described.

The reason it worked in my case was that for a 2d game, the state of even the maximum sized entity was very small. For animated objects I had a per-entity integer that stored what frame to display. The texture and animation data was stored elsewhere outside the table, but that was also loaded before the game started so there was no allocation after that point.

For a 3d game with complex animations it would be foolish to try to store all the animation and texture data in the same table, but I'd probably do something very similar for the game state.

<comment><USER4> I've tried a lot of ways of structuring game data but I basically agree with this assessment. Simple game logic can usually be premised on a single "God Object" type of deal that contains every possible property, or if you're in a language that supports it, is just a form of dynamic type. In old 8-bit games bit packing and unions would be used to conserve memory, but the games generally weren't complex enough in architectural scope to require a generalized approach to custom data structures and containers - just a few for optimization's sake.

It took until the late 90's and some overenthusiastic misfires with class inheritance-based designs(they don't compose cleanly) for the modern component-driven styles to start emerging. The tradeoff being made in current engines is basically one of late vs early binding - it's easier to write tooling against a late binding system where you can attach more nodes arbitrarily(e.g. Godot's scene system), but your optimization potential is better if you can compute exactly the data structures and containers needed for each category of entity and asset(there's a talk from Handmadecon about how Destiny went too far down this path and worked themselves into a corner).

Edit: Also, the biggest sticking point for working a GC in games isn't really with the entity and asset management since pooling will suffice for guaranteeing the quantities of elements needed for any given scene; it's with algorithms that work with standard functions that expect a GC environment, like string manipulation.

</comment></comment></comment></comment><comment><USER5> Centralised memory management doesn't inherently conflict with a decentralised OO design.

If you refactor your object construction into factory functions, you can make the factory responsible for implementing the memory management, and the objects themselves responsible for implementing the memory use. The objects can be ignorant about the handle array. The objects can delegate any memory- related functions to the factory methods.

<comment><USER6> > If you refactor your object construction into factory functions

Given this article is about c++, no need for factory patterns or anything like that. You can overload the new operator on a global, and a per type basis and do it that way.

<comment><USER7> A potential problem with "operator new" is that it you can only have one allocator per type for the entire process. When you explicitly pass a factory, you can have separate factory instances.

<comment><USER8> Or if you template your types on an allocator, like STL does in some cases.

</comment></comment></comment></comment><comment><USER9> I use handles quite a bit in some rust code because you can't have self referential objects yet since rust does not have have immovable objects. While it felt like a huge hack in the beginning I really warmed up to the idea now.

<comment><USER7> Using handles instead of proper references is still a huge hack IMO, because you lose all the soundness checks that the compiler can do for references. It's a good thing that immovable objects are coming soon.

<comment><USER10> Why can't you just wrap handles into unique/referenced types?

<comment><USER11> You can, but that only solves part of the problem: keeping pointer types from being used as the wrong type. You still have the equivalent of use-after-free to guard against which the lifetime system tracks for you for pointers, but not for handles.

<comment><USER9> You can associate lifetimes with handles just fine.

</comment></comment></comment></comment></comment><comment><USER12> Oh hey, I recognize this memory pattern; it's also used in capability-aware software sometimes to implement capabilities, as a "capability list" or "c-list": [https://en.wikipedia.org/wiki/C-list_(computer_security)](https://en.wikipedia.org/wiki/C-list_\(computer_security\))

<comment><USER13> The file descriptor table too.

</comment></comment><comment><USER14> I'm old enough to remember programming for the original Macintosh which used handles and relocatable memory. It was a nightmare. Constantly locking, unlocking handles was a chore and error prone. I also remember early Windows APIs that had opaque handle-based memory allocations. Sometimes in life it's useful to check your history books and understand why some things were consigned to history.

<comment><USER15> Constantly locking and unlocking handles was the problem. The whole point of _having_ handles was so they could be moved around, and locking them defeated the purpose. People just created their own problems by dereferencing a handle and then wondering why their pointer became invalid and then locking stuff willy-nilly to prevent it.

</comment></comment><comment><USER16> I've done this when I've had heavily interlinked structures. I had a 3D physics engine with elaborate data structures for all the polyhedra objects. Vertices link to edges, edges link to faces, faces link to edges and vertices, and the collision detection system follows those links to compute the closest points on two nearby objects efficiently.

All those data items were structures in arrays, part of the "Polyhedron" object. All interconnections between them were array indices. The Polyhedron object owned everything for that polyhedron. Delete that and all the parts went away.

</comment><comment><USER17> Are we seeing the emergence of a generic software best practice of centralised state management emergence across the industry? This table based storage pattern is now common to: \- functional frontend apps via redux \- classical apps and server backends via relational databases \- game engines like the one mentioned here, and Unity's Entity Component System \- probably more systems I don't know about

It seems to me like separation of state and behaviours is one of those fundamental rules that should apply to most large software applications.

</comment><comment><USER18> I wonder if there's anyone who'd argue for bringing back the other kind of handles:

[https://developer.apple.com/library/archive/documentation/ma...](https://developer.apple.com/library/archive/documentation/mac/Memory/Memory-11.html)

I hope not.

<comment><USER19> This was my first thought too. For extra confusion, Mac handles were pointers to pointers managed by the OS while on Windows, a "handle" just meant a pointer to a struct.

<comment><USER20> > _Windows_

Originally, a handle was an index in a table of allocated memory blocks; the idea was to be able to move these blocks around without affecting the program.

<comment><USER19> Ok, like handles on Mac OS then. Maybe they saw that this idea didn't work out so great on the Mac.

<comment><USER21> They didn't have much choice at the time: [https://blogs.msdn.microsoft.com/oldnewthing/20041104-00/?p=...](https://blogs.msdn.microsoft.com/oldnewthing/20041104-00/?p=37393)

<comment><USER22> These books always reminded me of the Dungeons and Dragons manuals...

</comment></comment></comment></comment></comment></comment><comment><USER23> > However, the underlying design philosophy doesn't fit very well into a > classical OOP world

These problems indeed belong to a non-OOP view of programming. In OOP, the behavior is concentrated in objects while here a significant part of the behavior is concentrated in references.

I have been working on one possible generic solution which is called _concept- oriented programming_ [1] and where _references_ are first-class elements of the program where a great deal of the program behavior is performed during object access using these references.

One of the main ideas is that each object class is accompanied with a reference class. Such a couple is referred to as a _concept_ (hence the name of the model). If reference class is empty then we get normal OOP. If object class is empty then we can model normal values (which are passed by copy). Of course, we can build a hierarchy by inheriting the behavior of references and objects (which is different from the classical inheritance but generalizes it in case we have only object classes).

COP is still on early stage and cannot be used just because there are other quite serious unsolved problems. But I see that the problems described in this post are not exceptions - describing how objects are _represented_ and how they are _accessed_ is an important piece of _custom_ functionality in any complex system and it is precisely COP tries to formalize (along with some other tricky problems).

[1] [http://conceptoriented.org](http://conceptoriented.org) Links on concept- oriented programming (COP)

</comment><comment><USER24> From what I can tell: that while this memory-management strategy can stop a program from seg-faulting or from executing remote code, the style of programming is the same as with `malloc` and `free`. You still have to `alloc_texture()` and `free_texture()` in your code even if those functions return a handle instead of a raw pointer.

Some observations about the strategy based on the article:

      - It does *not* prevent memory leaks. It uses fixed size arrays, so once you allocate more memory
      than there is room in the array, then the program has to exit.
      - It does not prevent use after free. It just makes it easier to detect when this has happened.

This could make debugging easier in some situations. I do wonder though how it interacts with code analyzers.

Also this could work in any language. I wonder if it's common in game development for Android, because of Java and garbage collection spikes.

Oh, and another observation: I think this strategy is fully compatible with RAII and smart pointers. Smart pointers are implemented using malloc/free, and this strategy is isomorphic to malloc/free, so combining them should work fine.

<comment><USER25> The program doesn't need to exit, it can simply allocate a larger space, and it knows exactly what slots are in use and can preserve those indices.

</comment></comment><comment><USER26> So an object table, like in early Smalltalks?

[http://www.mirandabanda.org/bluebook/bluebook_chapter30.html...](http://www.mirandabanda.org/bluebook/bluebook_chapter30.html#TheObjectTable30)

I've always wondered what the performance impact would be on 64 bit, assuming 32 bit indexes: on the one hand, half-size for most pointers, on the other hand extra indirection and the size of the table.

</comment><comment><USER27> > Most of the following blog post is written from a game developer's > perspective, but should also apply to other areas ...

Video games are a special case where allocations and deallocations are often well scheduled and predictable. For the more general case, using a data type like _ivector_ [1] for the object arrays would provide the desired memory safety. It gives you the flexibility of safely accessing an object via index, iterator or (zero-overhead smart) pointer. Even though it's a vector (like _std::vector_ ) its iterators behave like list iterators. That is, after an insertion or removal operation, unlike indexes, they continue to point to the same item (not necessarily the same position) and they only become invalid when the item they point to is removed. In particular, they don't become invalid after a resize/reallocation operation.

So using _ivector_ 's iterators instead of index handles would allow you to safely perform insertion/removal operations if necessary.

Also, for performance reasons you may sometimes want to temporarily obtain a direct pointer to the item. _ivector_ allows you to obtain a zero-overhead smart pointer to the item that is guaranteed not to become invalid. [2] It does this by disabling "resize" operations on the vector while it exists.

[1] shameless plug: [https://github.com/duneroadrunner/SaferCPlusPlus#vectors](https://github.com/duneroadrunner/SaferCPlusPlus#vectors)

[2] [https://github.com/duneroadrunner/SaferCPlusPlus#make_xscope...](https://github.com/duneroadrunner/SaferCPlusPlus#make_xscope_vector_size_change_lock_guard)

<comment><USER8> The next step is to use the old structure called gap buffer, piece table or the more general zipper... And drop the pretense you are inventing something new. :)

<comment><USER27> Pretense not intended, thanks for clarifying. :) Rather than algorithmic novelty, the point is more that _ivector_ has an API and implementation that is memory safe (memory safety seemed to be an emphasis of the blog post).

As for those next steps, I'm under the vague impression that they aren't as popular these days because larger cpu caches have greatly reduced the cost of moving contiguous data in most real-world scenarios. So that more often than not the cache coherency benefits of simple contiguous data outweigh the avoidance of shifting some of that (contiguous) data.[1]

[1] simple microbenchmark of contiguous vs non-contiguous containers near the end of the article: [https://www.codeproject.com/articles/1087021/stable- iterator...](https://www.codeproject.com/articles/1087021/stable-iterators- for-cplusplus-vectors-and-why-you)

<comment><USER8> Exactly why a gap buffer, piece table and zipper are a thing. These structures are optimized exactly for local modification, especially chunked or contiguous. These are semi-contiguous structures.

At some point with bigger data you will hit the brick wall where the memory move is too expensive. This is typically at a bunch of megabytes in size for localized block inserts. The idea of these only slightly more advanced structures is to amortize the cost or defer it.

For instance, a gap buffer is essentially 3 vectors/arrays. Piece table is a few more, merged as needed, usually few. A zipper can mix contiguous (potentially heap) access with tree structuring for rarely modified or accessed parts.

As for iterator stability. Either the structure knows about a active iterators (expensive) and fixes them up or you should probably use plain old pointers as such. Bet you didn't know you can and should use a pointer as an iterator to a contiguous memory... And if you really for some reason do need to hold stable iterators to anything, std::array is good enough. Remember you cannot safely resize due to potential for memory copies on reallocation. (yes there are tricks, no they're very not cheap nor threadsafe nor concurrent) The consistency model of ivector iterators is not quite explicit.

</comment></comment></comment></comment><comment><USER28> I starting using rust recently and I noticed my programs tend to use the techniques described in this article. Using an "object" pool that is responsible for the creation / management / destruction of values and their referencing is a good way to reason about lifetimes when you need to manage DAGs or graphs (where reference ownerships and lifecycles are hard to reason about).

</comment><comment><USER29> This feels like your recreating something equivalent to database tables with a numeric id index.

</comment><comment><USER30> One downside to this approach as far as I interpret it,

        widget_handle widget = widget_manager_new_widget(manager);

is that it appears to require the user to either remember two values,

        widget_tweak(manager, widget);

or the developer to push a variable into (at least) file scope,

        widget_tweak(widget)
        {
            actual_widget = widget_manager_lookup_widget(manager, widget);
        }

That's not super nice.

Most of the benefits described can be had by using pools rather than a naive heap allocator.

Seem like a nice way to hide bugs, though.

<comment><USER31> I think there is meant to be only one "manager" per object (thus, handle) type.

<comment><USER30> I had envisaged my 'manager' variable above as type widget_manager. Having a global manager of all things, or independent manager makes no difference to my argument.

The manager has to live in file-scope or above since there is no room in the handle to save a reference to it. At that point, you're creating a singleton and reducing the flexibility of the module. You now have all the usual issues with globals and singletons.

Unless of course you're passing around structures containing a handle and pointer to its manager...

<comment><USER32> There is nothing wrong with globals and singletons. They are very good patterns. Some areas of code deal with global state, and there is no sense in pretending it is not so. On the other hand some other areas definetly need a closure of their own (like a workload dumped to a worker thread).

The usual issues with globals pop up when people whant to run shortcuts and never implement the data separation from global to local when they should, think they can be used to replace a database like system, or - the horrors - use some multi level stack based system to push and pop global state as they merrily progress along the call stack - i.e run computations while using the global state as some sort of auxiliary storage unit.

<comment><USER8> Generally it is better to have a context with a well defined lifetime rather than the other two options.

Additionally thread safety puts very stringent requirements on global state, further making singletons and language goals worthless with few exceptions.

</comment></comment></comment></comment></comment><comment><USER19> Centralized resource management, public index handles... So basically OpenGL? (They're called "object names" rather than "index handles" in OpenGL, but the principle seems to be the same.)

</comment><comment><USER33> How does shared_ptr work? Reference counting?

No wonder that's slow and wasteful of both cache and branch prediction. What's wrong with using a proper generational moving garbage collector?

<comment><USER34> > How does shared_ptr work? Reference counting?

Yep.

> What's wrong with using a proper generational moving garbage collector?

Because then you don't have deterministic performance which is necessary in certain contexts–or am I misunderstanding you here?

<comment><USER33> Deterministic performance hasn't been a thing since the early 90s. I'll settle for just performance.

But sure, there are cases where you want the level of predictability of reference counting, in which case I'd rather take the performance penalty than spend time and pollute the codebase doing a lot of tricks to arrange memory as a compacting garbage collector would.

</comment></comment></comment><comment><USER35> I think OO would be way faster if instead of keeping all of the object properties together in memory and dealing with one object at a time you'd have object collection as you base type (you rarely have one of anything in you program). It would have array for each object property and you would never access change or pass whole one object, just specific properties of specific object. This should be very cache friendly.

<comment><USER36> Then how would subtype polymorphism work?

<comment><USER35> If you just want to inherit from the object collection you already have to have new object collection that behaves slightly differently then it should work exactly the same way as usual.

If you wanted to have different types of objects in one collection first you'd have to ask yourself if you really need to keep them together. But if so I suppose you'd just put base fields in one collection and new additional fields in another. Then handle to derived object would consist of two indexes, one in the base collection and the other in the collection of additional fields. Methods that access base field would need to use first index for them, and second index for additional fields.

Not sure if I'm being clear enough. Imagine you want to store collection of various subtyped objects in the database. This is pretty much the same problem. You keep base fields in one table, and specific fields in other tables (one for each subtype), and if you want to operate just on base fields you use base table, but if you want to operate on fields specific for a subtype you join base table with table that contains fields specific for that subtype.

</comment></comment></comment><comment><USER37> The method of filling spare bits with random values to guard against stale object access seems like it would probably work well in practice, but is there a way to make it 100% air-tight and guarantee that stale object access will always be prevented? Otherwise it seems like that could end up as the basis of a security vulnerability in a program that uses this pattern.

<comment><USER38> It's only a security vulnerability if there is a bug already present in the code. This mechanism is not introducing the vulnerability. In fact, it's helping find out the bug during development. At release runtime, the spare bits should always match.

<comment><USER37> I mean that if an object is deleted and its space in the array is reused for a new object, there's a small but non-zero chance that the spare bits will be identical, in which case the code would gain access to the new object when it is not supposed to. Or am I misunderstanding how the handle concept works?

<comment><USER38> Yeah, I think you are misunderstanding something here.

Yes, there is a non-zero chance that spare bits will be identical. But that's only relevant, if you have a bug in your code wherein you are trying to use a destroyed handle. If you are never using a destroyed handle, then the spare bits being identical is completely okay.

Another way to think of this is that the spare bits are optional. The interface is good even if there were no spare bits. The spare bits only add an additional probabilistic security check.

<comment><USER25> The fact that it's probabilistic is what makes it unreliable as a real security check. That's how I understood the original poster's concern. It might also lend a false sense of security, like most other solutions that don't actually solve the full problem.

</comment></comment></comment></comment></comment><comment><USER39> * >A good example for this 'system domain knowledge' is the destruction of rendering resource objects with modern 3D APIs: a resource object can not simply be destroyed immediately when the user code says so because the resource might still be referenced in a command list waiting to be consumed by the GPU. Instead the rendering system would only mark the resource object for destruction when the user code requests its destruction, but the actual destruction happens at a later time when the GPU no longer uses the resource.*

This is exactly the same behavior you get with shared_ptr, both the user code AND the rendering system would hold a reference to the object and it would only be deallocated once BOTH of them destory their shared_ptr. weak_ptr allows even more fine grained control.

You still need to manage your resource lifetime somehow, with either some equivalent of unique_ptr or shared_ptr. Otherwise you've just reinvented global variables. How else would you know when to free an object from your object pool? A "least-used" pattern could be useful in some scenarios but then you also need to be able to reconstruct the object again in case someone asks for it after a long time of being idle (like swapping to disk).

</comment><comment><USER40> I am actually trying to implement generic pointers in Rust, that could safely work with object pools and/or preallocated memory regions of arbitrary bitness.

My struggles are here: [https://github.com/lostmsu/mem_bitness](https://github.com/lostmsu/mem_bitness)

</comment><comment><USER24> An implementation: [https://github.com/jkabrg/type-segregated- pools](https://github.com/jkabrg/type-segregated-pools)</comment>


Classes Are Making Me Sad - <AUTHOR> https://gist.github.com/bathos/b134b7559161ddb80e53b3ee4cca253f <comment><USER2> I'd love if we could have a better conversation about JavaScript than "the language is bad and if you like it in any way you should feel bad" but seemingly not today.

To create a bit to the discussion, I feel like the class abstraction in ES2015 is mostly a mask that doesn't do people any favors - it makes one think they know what is happening but leads experienced programmers to false reasoning and much head banging. I've highly preferred a more functional style for most of my projects and teams - I wish there were better standard tools for enforcing style, as organizationally it's harder to get everyone on the same page than with more mature OOP tooling (which OOP patterns/strong typing makes easier to build).

<comment><USER3> Really, the largest problem I see in javascript is exactly how it doesn't have a lot of features to enforce style.

Sure, there is some other wonky stuff, but the ease with which one can write bad javascript is the core issue.

<comment><USER4> This is a relatively solved problem with a proper .eslintrc and a style guide. You can pick two of the most popular -- airbnb or standardjs, npm install their eslint rules, and go on your merry way. Rolling your own and/or extending these is relatively simple.

</comment></comment></comment><comment><USER5> Whoever at Netscape vetoed Scheme as the browser language should be on trial in The Hague.

<comment><USER6> The short story has it that it was some Java-pushing dickheads from Sun Microsystems.

<comment><USER6> You may dislike my tone, but it is basically factual.

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

Eich> I joined Netscape on April 4, 1995, to "do Scheme in the browser". Immediately I was out of luck on several fronts:

Eich> [...]

Eich> If there was to be a "scripting language", it had to look like Java.

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

Eich> Remember, I was recruited to "do Scheme", which felt like bait and switch in light of the Java deal brewing by the time I joined Netscape.

<comment><USER7> Cool. This explains why the better I understood Clojure, the more my Javascript started to look lispy.

</comment></comment></comment></comment><comment><USER8> Every time I think I understand Javascript, I read something about its prototypes and constructors and how 'new' and 'this' works and I am lost again.

The thing I like about classes is I vaguely understand what is going on and why, coming from Java and similar. So I am using them, together with Flow typechecking.

I am not saying the javascript prototype logic is bad, just that I never understood it, even when I work in Javascript for years.

Sometimes I understand, for a brief moment, "how", but never "why".

<comment><USER9> > Every time I think I understand Javascript, I read something about its > prototypes and constructors and how 'new' and 'this' works and I am lost > again.

Prototypes, constructors, and context are not that complicated; I encourage you to keep reading and trying things. You may be surprised how quickly you end up "getting" it.

> The thing I like about classes is I vaguely understand what is going on and > why, coming from Java and similar.

No. The class keyword in JS is syntactic sugar around the same prototype stuff that already existed. It does not work like it does in Java, and you will not understand what it's doing unless you understand how the class keyword translates directly into manipulating the prototype chain.

Which, as above, is easy! But if there's one _actual_ problem with the class keyword it's that it makes people who know Java think they understand JS inheritance.

The class keyword _DOES NOT CHANGE YOUR CODE_. If you didn't understand what was going on before you used the class keyword, you don't understand it after adding it in. (Conversely, if you actually do understand how the class keyword works, then rejoice, you now understand how prototypes work...)

<comment><USER10> > _Which, as above, is easy! But if there 's one actual problem with the class > keyword it's that it makes people who know Java think they understand JS > inheritance._

Which is totally fine, as for all intends and purposes the behavior is the same. You create new instances, and you call methods on them.

The "movable" context (this) will be a little surprising, but for everything else one can write JS for decades with ES6 classes and "OOP", without having to know how the prototypes, objects and functions they de-sugar to work.

<comment><USER7> > Which is totally fine, as for all intends and purposes the behavior is the > same.

Nope :) They're _apparently_ the same, which is not the same as "the same".

> The "movable" context (this) will be a little surprising, but for everything > else one can write JS for decades with ES6 classes and "OOP", without having > to know how the prototypes, objects and functions they de-sugar to work.

That's just the thing though - there isn't a "movable context", there is only binding. Binding usually happens implicitly, and most of the time things are implicitly bound to what you expect them to be if you're not aware it's happening.

... then comes the moment that you're in an instance's method, and `this` is pointing to an event instead of the object. Oh, boy.

In my experience that moment comes much more often than once every few decades.

</comment></comment></comment></comment><comment><USER11> Wonder what the language would now look like if we had some dedicated syntax for Object.create instead of hiding the underlying prototype mechanism under the familiar class syntax.

        typeof (class {}) === "function"

This is almost guaranteed to be a future WAT[1] moment for the next generation of JavaScript programmers.

I can already see that a big part of the appeal for classes is that they keep your code looking neat and succinct (as opposed to throwing .prototype and Object.create all over the place.

I'd much rather be writing code that looked something like the below, than having to think about super, static, own properties, constructors, private fields etc.

       // provided by some view library
       let Component = {
         state: null,

         setState(state) {
           Object.assign(this.state, state);
           this.forceUpdate();
         }

         // ...
       }

       let Counter is Component {
         get state() {
           return { count: 0 };
         },

         inc() {
           let { count } = this.state;
           let { step } = this.props;
           this.setState({ count: count + step });
         },

         render() {
           let { count } = this.state;
           return <button onClick={this.inc}>{count}</button>;
         }
       }

       render(<Counter step={2} />);

Although it introduces a new keyword, the abstraction ends up being minimal, because it's just a sugar for the existing Object.create.

       // let Counter is Component
       let Counter = Object.create(Component);

This is obviously a very half baked idea, but I have programmed quite happily with Object.create for a long time without ever _needing_ to use classes. If we had better tools for working with prototypes then maybe we wouldn't have to pretend the language had classes instead.

[1]: [https://www.destroyallsoftware.com/talks/wat](https://www.destroyallsoftware.com/talks/wat)

</comment><comment><USER12> As someone who works mostly in React I've never found a use for classes. It's a contentious, messy feature that solves problems I don't have.

I used Coffeescript classes in the old jQuery/Backbone days and they were useful only because the rest of the ecosystem was so terrible.

<comment><USER9> > As someone who works mostly in React I've never found a use for classes.

You can't NOT use classes if you use React. [Edit: For components with state] your syntax choices are:

        Foo = React.createClass({})

Or:

        class Foo extends React.Component {}

But both are examples of JS classes; it's just a question of whether you use the class keyword or not. Every React component [Edit: with state] is a class.

Edit: Fixed silly error; obviously you can use stateless functional components and I do all the time, but you can't avoid classes with React.

<comment><USER13> I tend to heavily favor functional components[1]:

        function Welcome(props) {
          return
Hello, {props.name}
;
        }

or a little nicer:

        const Welcome = ({ name }) => (

Hello, {name}

        )

[1]: [https://facebook.github.io/react/docs/components-and- props.h...](https://facebook.github.io/react/docs/components-and- props.html#functional-and-class-components)

<comment><USER9> Sorry, typed too fast. Edited my answer to clarify.

</comment></comment></comment></comment><comment><USER14> JavaScript is not an object-oriented language, but a prototypical one. JS "classes" are really an attempt to use syntactic sugar to beat one concept into another. This is inherently ugly.

For anyone convinced they hate JS, I encourage looking through Crockford's _JavaScript: The Good Parts_ , in which he talks about the idea mentioned above, before swearing off JS forever.

<comment><USER15> > JavaScript is not an object-oriented language, but a prototypical

Prototypical languages are a subset of OO languages, despite the fact the the industrial popularity of a handful of class-based OO languages (especially C++ and it's descendants) starting in the late 1980s have made it so that many people confuse OO with specifically class-based OO.

<comment><USER16> The first object-oriented languages—Simula and Smalltalk—were class-based, so when "object-oriented programming" was coined, it implicitly included classes. _Every_ OOP language had classes.

Only later when Self came out was the term broadened to include languages oriented around objects _without_ classes.

Sure, we need to be more precise today and refer to "class-based object- oriented" and "prototypal object-oriented", but that's not a fault of the class-based languages. They laid claim to the general term first.

Before horseless carriages, all carriages had horses, so it seems unreasonable to expect people to have presciently called them "horseful carriages" even before automobiles were invented.

<comment><USER17> [http://userpage.fu- berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...](http://userpage.fu- berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en)

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."

Simula has classes, but Alan Kay's "object oriented" wasn't about classes at all.

</comment></comment></comment></comment><comment><USER18> I always thought that Javascript kind of is modern Lisp, apart from all the parens. Radical freedom means everybody implements their own classes, promises, all kind of stuff that is out of the box in other languages — which makes us happy because we can play with it, but then makes everybody unhappy when we try to bring our toys together. And when somebody gets their way in deciding what is the _right_way_ to play, all the rest of us get even more unhappy.

</comment><comment><USER19> Me I am sad about how unreliable comparison operators are.

We fix equality by using === instead of ==. == is so bad that it is not transitive if a==b && b==c you are not sure c==a

And everytime we use <, <=, >, >=, cmp we are back at using == implicitly, which triggers so many problems and bugs (and sort relies on them, thus sort is also broken).

If a language cannot do simple math correctly, it should never be used for stuffs related to commercial transactions or security... anything serious.

</comment><comment><USER20> Javascript is making you sad.

</comment><comment><USER21> > Classes Are Making Me Sad

And they are in the spec. It's too late to be sad about that, people are going to use them and they should.

</comment><comment><USER22> There isn't really a need for classes...

</comment><comment><USER23> Comunism for you then. Let's end the class struggle!

PS: This comment does not intend to be productive in any way.

</comment><comment><USER24> Try Elm?

<comment><USER25> Not OP, but I just finished a small trial phase with it.

There's no straightforward way to make nested record updates. You have to write separate setter functions for every step of the way.

If you don't list every single mutation in a single type, and have a single update function to handle them all, you're in for an exhorbitant amount of boilerplate to wire it all. Long, single file types and functions with Objective-C style namespacing are idiomatic.

All is good error wise, until you have to use the escape hatch to JavaScript, in which case good luck building a separate castle of abstractions to fit both of them together and debug it.

There's also the fact that the language creator has to bless a set of bindings before they're allowed to be packaged and uploaded. I do not know how this works out in practice, but it certainly made me raise my eyebrows and not in a good way.

In summary: It's a promising language, but using it to build large codebases either involves techniques the community doesn't know about or it's an exercise in masochism. Maybe in a few years it'll be good.

<comment><USER24> Thanks for the insight; we're also evaluating Elm, but our code base isn't large, and we committed to using flat records. Good point about the nested record handling.

<comment><USER25> For what it's worth, I am analyzing it again after making a small prototype of the application I needed it for but using Vue + Vuex. It's helped me put in perspective the amount of boilerplate needed by Elm, and now I'm not so sure that particular downside is as big compared to the alternatives as to disqualify it...

I'm going to give it another full week before going one way or the other.

</comment></comment></comment></comment><comment><USER26> If only ES were more like E or Monte, where there are no classes and no `this`.

</comment><comment><USER27> Javascript is making you sad.

</comment><comment><USER28> How much energy will be spent thrusting this regressive pig?

<comment><USER29> More than will be spent thrusting all other barnyard animals combined?

</comment></comment><comment> d--b Dude classes are making you sad? Man, you should shield up, _a lot_ of things beyond classes are going to make you sad. Classes and javascript are a history between 2 different clans fighting together and no one winning, but it's still javascript. Not a huge deal if it's shittier than it already is. I like the language don't get me wrong, but there is so much in there that's unpleasant, that another construct shouldn't affect you much.

</comment><comment><USER30> Having used JS along with somewhere north of 10 other languages over the years... JS is the most painful, even moreso than Perl which was close.

Classes and objects are 100x better than the crap they've come up with to fix JS so far so stop complaining.

Oh no it's not functional???!!! Javascript never was. It was always supposed to be an OO language the implementation is just shit. For the love of God everyone just shut up and let them fix it. Trying to change JS from what it was meant to be into something else entirely is just going to make things even worse</comment>


Libdill: Structured Concurrency for C (2016) - <AUTHOR> http://libdill.org/index.html <comment><USER2> Ok, I'll chime in here since all the comments are missing the point.

If you are excited by golang-style in C, then Mr Sustrik's libmill is for you [http://libmill.org/tutorial.html](http://libmill.org/tutorial.html)

LibDill is a thin experiment "above" of libmill. The main problem it tries to solve is "cancellations". For the uninitiated, in normal programming languages there is no way to cancel/interrupt a tread/coroutine from outside. Look at the mess in pthread_cancel(3) [1]. In golang as well, there is no way to cancel a coroutine.

Why this is important? Well, read Mr Sustrik's notes [2]. But basically - imagine you want to define the time limit for a completion of some task. Or - imagine what should happen if a HTTP request comes, initiates some actions (SQL quieries?) and then disconnects. Normal programming languages have _NO_ way of expressing that - "client went away, stop processing its sql queries".

Libdill is an attempt to solve this. I must admit, I'm not fully on board with the "structured concurrency" train of thought [3] , but the whole prospect of defining semantics of killing/cancelling coroutines is absolutely amazing.

Also, review the golang "context" mess, which AFAIU tries to work around the same problem. [4]

[1] [http://man7.org/linux/man- pages/man3/pthread_cancel.3.html](http://man7.org/linux/man- pages/man3/pthread_cancel.3.html) [2] [http://250bpm.com/blog:71](http://250bpm.com/blog:71) [3] [http://libdill.org/structured- concurrency.html](http://libdill.org/structured-concurrency.html) [4] [https://golang.org/pkg/context](https://golang.org/pkg/context)

<comment><USER3> Not sure why don't you like go's context model. It works pretty well in our production system. I can see people would like to pass the context implicitly. But I don't have a strong opinion. Explicitness is not that bad.

<comment><USER4> Context is problematic because it infects everything. If a function gains context support, every call to it has to be updated, and if you're going to do it right (and not just use context.Background()), every function calling _those_ functions need to be updated, and so on. And the context has to be passed downwards, too. It's turtles all the way up and down.

There's been talk of adding context to io.Reader and io.Writer, which would of course affect pretty much every single Go codebase. For backwards compatibility/convenience you therefore see a lot of APIs with complementary functions Foo and FooCtx, one which takes a context and one that doesn't. That's awkward, and even less elegant when interfaces are involved.

And the network packages (sockets, etc.), of course, have a parallel, non- complementary mechanism to provide timeouts and cancelation that doesn't use contexts. (The key/value pair context stuff is also unfortunate, in my opinion. It's not typesafe, and results in awkward APIs.)

All of this happened because goroutines, as designed, cannot be forcibly terminated. I don't know what the better solution is. I'm not sure why the runtime cannot provoke a panic at the next context switch, but I bet there's a good technical reason. It's unfortunate.

But it's not unreasonable that a large part of any codebase needs "contexts", and so if everyone wants it, why not make it mandatory? Make it an implicit argument threaded through every function call, a bit like "this" in languages such as C++ and Java. The compiler could optimize it away from those codepaths that are guaranteed not to need it. Go has a lot of built-in generic magic, adding some global helpers to set a scope's context wouldn't be too bad.

The other route is to imitate Erlang's processes, which have their own heap, and so killing a process doesn't leave cruft behind. Given how goroutines are allowed to share memory, that's not likely to happen.

<comment><USER3> I see. Now I see a strong point of favoring implicitly passing the context - attaching the context to a go routine local variable (no such thing yet), so the aspect of context passing can be decoupled. Of course for some logic we probably still want to do some explicit context stitching, but that won't pollute most of interfaces. Would that address your concern?

</comment></comment></comment></comment><comment><USER5> >There is currently no support for Windows. Cygwin is very broken. It doesn't support AF_UNIX properly, and so no further development will be done for this platform.

Boy do I have good news for whoever wrote this:

[https://blogs.msdn.microsoft.com/commandline/2017/12/19/af_u...](https://blogs.msdn.microsoft.com/commandline/2017/12/19/af_unix- comes-to-windows/)

<comment><USER6> Doesn't sound great if a coroutine library has resorted to passing messages across sockets. I was expecting something that implemented multiple stacks and some abstraction of some synchronization.

<comment><USER7> It appears to do that: [https://github.com/sustrik/libdill/blob/master/stack.c](https://github.com/sustrik/libdill/blob/master/stack.c)

<comment><USER8> Correct. It does that. The IPC, on the other hand, is there for you to use if you want to talk to other processes on the same machine.

</comment></comment></comment></comment><comment><USER9> I really liked the Linda concept for concurrency but it doesn't seem to have caught on in general. It isn't the same as what is being presented here but it side steps the threads issues, the multiple cpu issues, all that falls out for free. Seemed pretty cool and I suppose you could layer on cancellations (but I suspect it would be a mess like pthread_cancel()).

[https://en.wikipedia.org/wiki/Linda_(coordination_language)](https://en.wikipedia.org/wiki/Linda_\(coordination_language\))

[http://linuxtuples.sourceforge.net/](http://linuxtuples.sourceforge.net/)

Anyone else like that stuff? Or have any insight why it isn't more widely used? Maybe it's because it was a commercial thing?

</comment><comment><USER10> I was confused -- how can a library add a keyword like "coroutine" to C. It didn't look like macros were powerful enough to do that (I expected to at least some context having to be passed to the worker, or so).

It turns out that a coroutine is just a function that the compiler should not inline: [https://github.com/sustrik/libmill/blob/master/libmill.h#L24...](https://github.com/sustrik/libmill/blob/master/libmill.h#L242)

<comment><USER8> Yes, it's just a normal function. What go() macro does is that it switches the stack, then lets compiler-generated code put the args of the function at the top of the new stack. Obviously, if the function was inlined, the above would not work.

</comment></comment><comment><USER9> The fact that this is all on one cpu seems like a problem, does it not?

Does someone have a mental model of how to take advantage of multiple cpus without creating a mess? If so, can you explain it like I'm 5 (or more like I'm 55 and tired)?

<comment><USER8> I think the environment is a bit different now than it was once.

You typically have a cluster of machines, so you have to be able to run multiple instances of your application simultaneously to use all the processing power. And once you can run mutliple instances of the application in parallel you can as well run 16 instances of it on a 16-core box.

The upside is that you don't have two levels of granularity (threads, machines) but only a single one (processes) which makes both the coding and the ops as well as stuff like capacity planning much easier.

<comment><USER11> Even absent the cluster of machines I found this to be very useful. Several years ago, I would use zeromq (thank you, btw) for communication and if the socket overhead was found to be an issue, I would merge two processes and switch from tcp:// to inproc://. Many "corrupt the world" type bugs are isolated from each other by processes, and it made it very hard to accidentally share state (the file system of course is a giant hunk of share state, but you very rarely accidentally write to a file).

</comment></comment></comment><comment><USER12> I took a peek at the source briefly. There is a lot more going on than I was expecting and was pleasantly surprised. I was expecting to find a simple wrapper around setjmp/longjmp, but this is much more. Kudos.

</comment><comment><USER13> > coroutine void worker(const char *text) {

At first I read 'goroutine' and thought something is wrong with my mind and that I have coded too much Go. But then I saw this:

> go(worker("Hello!"));

Now I am pretty sure someone got inspired by Golang ;-) Nice to see some backporting of Go features to C.

Note: That doesn't mean that Go is the only language that supports easy concurrent patterns, but that the creators of Go wanted to improve C and while not everybody agrees that all they have done are improvements, making concurrency easier most certainly is one.

<comment><USER14> I think it's fair to say that Go was hardly the first language to implement the concept of coroutines[1]. Probably the only merit of Go here is the short and convenient name of the 'run' method.

[1] [https://en.wikipedia.org/wiki/Coroutine#Implementations](https://en.wikipedia.org/wiki/Coroutine#Implementations)

<comment><USER15>
        > libmill was a project that aimed to copy Go's
        > concurrency model to C 1:1 [...]

        > libdill is a follow-up project that experiments with
        > structured concurrency and diverges from the Go model.

[http://libdill.org/documentation.html](http://libdill.org/documentation.html)

</comment></comment></comment><comment><USER16> Very nice!! I look forward to reading through all the structured concurrency stuff later.

</comment><comment><USER17> so what is this different from pthread? how can I decide to pick one of them?

the new C11 has thread built-in but not used widely yet.

</comment><comment><USER14> I read that NodeJS is written in C with the same concept in its core - asynchronous on one core (thread) with interruptions. How does it compare to libdill?

<comment><USER18> Node runs on top of libuv. [https://nikhilm.github.io/uvbook/basics.html#hello- world](https://nikhilm.github.io/uvbook/basics.html#hello-world)

<comment><USER14> So it looks like libuv _could use_ libdill, right?

<comment><USER19> Could have, possibly, but makes no sense at all to retrofit libuv with libdill at this point

<comment><USER20> Shameless(-ish) plug: [https://github.com/piscisaureus/wepoll](https://github.com/piscisaureus/wepoll) is not a fat abstraction layer but it could help with windows support.

<comment><USER19> Libuv supports windows and in some ways only exists because windows support is needed; on Unix/Linux where Node started, libev was sufficient; libuv was created to facilitate the windows port of node - though it is now standing in its own right.

<comment><USER20> I know - I am one of the authors of libuv. However libuv is pretty big and imposes its own asynchronous i/o model onto your application.

Later I discovered that it is possible to do efficient epoll emulation on windows so then I wrote wepoll. With it you can just stick to the good ol' epoll/kqueue model and still support windows.</comment></comment></comment></comment></comment></comment></comment>


Google sells Frommer's brand back to Arthur Frommer - <AUTHOR> http://venturebeat.com/2013/04/04/google-sells-frommers-to-arthur-frommer/#5SLBme2u5lMExfqH.99

<comment><USER2> Google is so bad at everything; and not good at anything. They are a virtual black hole of suck. I say that even though I own stock and reluctantly use their products even though I am pretty much just a single decent reason away from moving. They can't even get their own products working well, how the heck do they think they can integrate and improve on something they bring in from the outside. For all things that are good, Google, just let well alone and simply support your acquisitions with some strategic guidance to come in line over the long-run......without strangling them.

How long has it been since they suffocated Sparrow???</comment>


Microsoft Issues Windows 10 Upgrade Warning - <AUTHOR> https://www.forbes.com/sites/gordonkelly/2019/01/26/microsoft-windows-10-upgrade-storage-space-problem-price-cost/#34881942f024 <comment><USER2> I'm always impressed by people's creative ability to put a negative spin on almost anything. Particularly to generate hate-clicks.

In this case they're implementing Seamless Updates, which should substantially reduce downtime and improve roll-backs during update installation (a major complaint) but instead of focusing on the benefit, they focus on the disk space loss.

The reason it takes up space on Windows, Android, and Chrome OS is that the reserved area holds a chunk of the operating system which is updated in the background before restart. When a restart occurs, the reserved and active slices are swapped (and reversion can be rapidly conducted for failures/roll- backs).

This is a nice quality of life improvement for a common complaint.

<comment><USER3> it's a nice quality of life improvement unless you're running low on space. 7+ gb is _a lot_ , especially on embedded devices with low soldered storage - like microsoft's own products! coincidentally instead of offering upgradeable internal storage they upsell really hard on the models with more storage in their surface lineup

if anything, this should be a toggle- if only an opt-out toggle.

fwiw, you can install a linux system including an entire graphical stack with web browser and mail client in that space, twice.

<comment><USER4> This is also going to be a major pain on my Windows VM's. I often only give those ~32 GB of storage to begin with, since they're only for a tiny handful of programs.

I'm assuming there will be a group policy setting I can change, though, since I'm lucky enough to have Windows 10 Pro...

</comment></comment></comment><comment><USER5> I can't answer this because the most likely location for the answer [1] is locked behind a beta program access or something, but where do they plan on taking the reserved storage from? I assume they're not going to try to repartition the drive? It sounds like they're just using filesystem features to carve it out of an existing partition, but I'd like to be sure. My laptop is currently dual-boot, but if Microsoft starts blindly mucking with partition tables it's gonna go single-boot Linux right quick. (I _expect_ it's not that, but I'd like to be sure.)

As long as they're staying out of the partition table, this sounds like a good idea to me, honestly.

[1]: [https://insider.windows.com/en- us/ih/?contentid=2762bf7a-bef...](https://insider.windows.com/en- us/ih/?contentid=2762bf7a-bef0-4835-8e4c-04ae8e3ed299&contenttype=quest)

<comment><USER6> I have no clue either but my guess is that they will just use a sys file like hibernate or pagefile. Most people will never see it and those of us that peek at hidden, system files once in a while will most likely not be able to mess with it easily due to permissions.

At least I would hope they would do something like that, I agree a method which messed with partitions would be a complete show stopper!

</comment></comment><comment><USER7> Interesting... Microsoft is forcing everyone to update their machines for quite some time... I've noticed that MS is forcing updates on my machine about a year ago and out of frustration I asked about it on this forum four months ago ([https://news.ycombinator.com/item?id=18029216](https://news.ycombinator.com/item?id=18029216)) Please try it. Go to Computer Management/Services and Applications/Services and then stop and disable Windows Updates. It's a matter of days before it will be back and running again. My next machine is going to be Apple.

<comment><USER8> I presume the first thing you'll do on your next Apple machine is disabling updates.

Don't forget to also disable auto-updates in Chrome/Firefox, since they are enabled by default.

<comment><USER9> I think the gripe was less about auto-updates than the fact that the OS allegedly un-set OP's attempt at opting out.

Forgetting certain settings is annoying. Forgetting that I want to manually control when my computer downloads gigs of data to apply a patch that- in recent times especially- may very well brick my system... well, I can certainly understand where OP's frustration comes in.

Even at one of my jobs a few years back (which was about 50/45/5 apple / windows / linux shop) we were cautioned against applying major updates from apple within the first month or so of their releases given past issues.

<comment><USER8> I wouldn't call disabling the Windows Update service as "setting an option" that it's later forgotten. It's more of a thing an inexperienced user does by mistake while messing around. Windows does things behind you back, like magically restore system files if you manage to delete them, and so on, in an effort to keep running. But of course, some people are like "I deleted those files on purpose, so stay the damn out of my lawn"

But I do get your point, and Windows is indeed lacking an option to fully disable updates, even if it does have an option to defer major updates by up to an year.

<comment><USER10> Windows also collects what pirated software you run and - on buisness success sells you out to the vendor of said software. Guess the crack did not work..

<comment><USER11> Not that I don't believe you, but I'm gonna need a citation for that

</comment></comment></comment></comment></comment></comment><comment><USER12> I don't understand why the updates take up so much space -- 7GB according to the article.

<comment><USER13> It seems like the old "set your pagefile manually so you never have to worry about it growing/shrinking" trick from Windows of yore - they are grabbing that much so that they don't have to grab more at any time. It's basically a promise that, while those 7 GB are the systems now, you'll never have a problem where you run out of storage space due to an update (assuming after they reserve the initial 7 GB).

</comment></comment><comment><USER14> It's not a warning - this only affects new PCs shipped with the latest version, not upgraders.

<comment><USER15> "at this time"

<comment><USER16> Exactly. Running Windows now is like playing roulette. How will this feature work in a month, "no idea". How will I change this option in the UI, "no idea". Will this option I set for important privacy setting stick after the latest (automatic) upgrade, "no idea. Ad infinitum. :/

<comment><USER13> It's like using a Google product.

<comment><USER16> Yep, and the effect of having this happen on a mass scale across all major providers/players in the software/IT field is that humanity is collectively left spinning it's wheels aimlessly (literally million of years in lost real time) instead of going from a to b using a set of tools.

If our cars behaved in similar ways (the gearstick is sometimes in one place sometimes in another and the way the wheel works changes at random while the glove compartment could at any one time be found in a new surprising location) we would see the results instantly but because computing is predominantly desk bound the loss incurred is in many ways silent.

</comment></comment></comment></comment></comment><comment><USER17> One thing that interests me: How does a Windows 10 install + 7gb reserved space compare with a current Windows 7 install in terms of disk usage? I thought Windows 7 was "fatter" than 10?

</comment><comment><USER18> I'm fine with this. Android basically works the same way and I don't see anyone complaining about that.

<comment><USER19> I'm complaining. Android "System" takes up 13GB on my phone. That's too damn much!

</comment></comment><comment><USER20> Linux has the exact same feature, and has had it since approximately forever. By default, 5% of the disk space on any system partition is reserved for use by the superuser after the main 95% portion is filled up. And system updates run with superuser privileges, so... ¯\\_(ツ)_/¯

<comment><USER21> Differences:

\- It's configurable.

\- The space is reserved for the end user, not the OS manufacturer.

</comment></comment><comment><USER10> Introducing the Update Prevention Tool.. Continously writting into reserved storage to prevent updates.. in 3.. 2... 1

</comment><comment><USER22> I am glad that Windows is an opt-out of updates. We all know the majority of people never update anything. Personally I opt out and manually update my systems but most people just need it to happen.

<comment><USER4> When I set up Windows to encode a video overnight, and I wake up the next morning and the encode isn't finished because Windows decided to restart in the middle, I'm not happy. This basically means I can't use Windows to encode videos, period. (And no, setting Active Hours doesn't work, because the whole point is I want the videos to get encoded when I'm _not_ active!)

The same applies to downloading large files, etc. I realize that updates are important, but it's even more important that I can actually rely on my computer.

<comment><USER8> You get a notification when Windows plans on restarting somewhere in the future. I just click on it and manually set the restart date 1 week in the future. That's it.

I'm also leaving the computer on for weeks and never had an unexpected reboot with this protocol.

<comment><USER4> This doesn't work if it's been a while since I last booted into my Windows partition. Windows immediately decides I'm past the point where I can defer. It does show a notification immediately beforehand, but if I'm asleep that isn't useful.

<comment><USER22> You can disable the Reboot task present under Task Scheduler Library > Microsoft > Windows > UpdateOrchestrator in the Task Scheduler app

I haven't had a Windows 10 computer just randomly reboot and I work with about 30 PCs.

<comment><USER4> Respectfully, if you're using the PC's for work I'm guessing they don't get turned off (or stay in alternate OS's) for extended periods.

I'll take a look at task scheduler, thanks.</comment></comment></comment></comment></comment></comment>


What's This Image at The YMCA? - <AUTHOR> https://medium.com/this-happened-to-me/cdcbc43689ec

<comment><USER2> It's a variant of the Chi-Rho symbol: [https://en.wikipedia.org/wiki/Chi_Rho](https://en.wikipedia.org/wiki/Chi_Rho)

<comment><AUTHOR> Awesome!! Thank you! Updated post to include your info.</comment></comment>


Hate Your To-Do List? Try A Rolling List Instead - <AUTHOR> http://www.lifehack.org/articles/productivity/hate-your-to-do-list-try-a-rolling-list-instead.html

<comment><USER2> I don't get it. How is this different than any other todo list? Who doesn't sort their todo list by some type of priority / due date?

Give it a cutesy name doesn't make it new or better.

<comment><USER3> Seems like it was written by a requirements engineer.

</comment></comment><comment><USER4> A Rolling list is good for long term planning, what you need to get things done is to write down only one main task per day, do that and the rest will come automatically. And stop using complex software for to-do lists.

<comment><USER5> I totally agree. The biggest mistake I used to make when stuff got complex was trying to get back "control" by "normalizing all the tasks": writing stuff down way ahead of time etc. I now do one task at a time, take a short break, then the next task.

</comment></comment><comment><USER6> This sounds like something along the lines of Getting Things Done, a to-do system where goals are broken down into actionable tasks that can be re- arranged as needed.

</comment><comment><USER7> The biggest problem with most to-do lists, I find, is that there's a tendency to write down _goals_ instead of _tasks_. Tasks are simply actions that you do in order to reach your goals.

Writing down goals is important, but they should be kept separately. The problem with writing down your goals in your to-do list is that you then see items like this:

* Plan fundraiser

and

* Fix bug that occasionally crashes server randomly

instead of

* Call restaurant to confirm date and rates * Select menu items for caterer * Write donation tax receipt for Mr. Smith's donation

and

* Find the bug (probably some problem with the new database sharding) * Write unit test for the fix * Fix bug * Write description of patch and submit to code review

The second one may be a bit overkill, but you get the idea. In my experience, 90% of to-do list problems can be solved by making the items _actionable_ as opposed to simply reminders of one's goals.</comment>


An in-depth look at the performance of guile's web server - <AUTHOR> http://wingolog.org/archives/2012/03/08/an-in-depth-look-at-the-performance-of-guiles-web-server

<comment><USER2> Work has been done with Guile to let it run emacs lisp. Hopefully, more can be done to finish this project. It would be great to have both elisp and Scheme as Emacs extension languages. More Google Summer of Code work?</comment>


Ask HN: Showing personal projects to potential employers - <AUTHOR>

I've heard that when I go to look for an internship one of the most important things for a potential employer will be the projects that I've done in my free time.<p>This will vary from employer to employer, but what is it that you would be looking for when you see my projects? What would get me bonus points and what would make me lose points? What is important to you? Good documentation and commenting? Optimization? Apparent effort? What is a deal breaker? <comment><USER2> Fortunately I landed an internship in a good company because of my portfolio, not my grades. They saw that I was developing quite a lot of stuff that was not really related to my degree and they liked it.

I would look for something related to the thing that company does, but a range of different thingies created just for yourself shows that you're creative, learn quickly and actually like doing this stuff.

Coding your own projects it's better than sitting and doing nothing so I guess that it's hard to "loose points".

<comment><AUTHOR> I'd like to get an internship with Mixpanel -- a web analytics company -- next summer so I've been reading up on data mining and I hope to get to work on a related project using Python in the next few weeks.

</comment></comment><comment><USER3> Speaking from my own internship experience:

1\. The type of project you're doing: If you're applying to a game company, then your projects better be about AI, particle effects, or gameplay related

Bonus points if what you are doing fits the job description (in terms of the language you use or what your project is about)

2\. Good coding practices (formatting, documentation, readability): Nobody wants to work with a guy who writes unreadable code

</comment><comment><USER4> I definitely agree with meric. I look at code samples/projects to gauge how good the developer is. Most likely the code will be read, not executed. So, good design is a huge plus, but well thought out programs or clever but readable code is a great-to-have. Documentation and commenting I ignore unless they're necessary (hard to read logic). I wouldn't OVER-optimize these projects either, since they'll simply be read over.

</comment><comment><USER5> If the company has an API, build something with it.

<comment><AUTHOR> Sounds like brown nosing to me. :P

</comment></comment><comment><USER6> In my short experience, any project > no project and complete projects > incomplete projects.</comment>


Pointer Overflow Checking - <AUTHOR> http://blog.regehr.org/archives/1395 <comment><USER2> The first example memcpy() code is semi-broken since it uses an int-type iterator variable which is compared against a size_t-type length. This would generate warnings from most compilers (signed vs unsigned) and is generally a bad idea, the iterator should of course have been size_t too.

Also there could have been more const, but that's almost always true. :)</comment>


Things to do in Paris by Night - <AUTHOR> Do check this out.<p>https://www.theblueberrytrails.com/index.php/blog/entry/47/ten-things-to-do-in-paris-by-night <comment><AUTHOR> We are The Blueberry Trails ([https://www.theblueberrytrails.com/](https://www.theblueberrytrails.com/))

We will even personalize a tour to wherever you wanna go and make sure you have offbeat experiences and unique moments to remember for lifetime.</comment>


Hyper social URL shortening service - vyu.me - <AUTHOR> http://vyu.me

<comment><USER2> Neat. I'll give it a try. Trending links are cool.</comment>


Rekapi Presentation - A keyframe animation library - <AUTHOR> http://www.techspringboard.com/bayquery-rekapi/ Jeremy Kahn demonstraits his Rekapi keyframe animation library for JavaScript at the BayQuery Meetup April 27th 2012. <comment><AUTHOR> Call to action: You can learn more about Rekapi at <http://rekapi.com/>. The project is still young and needs support from the open source community! Patches are welcome (and accepted), and more demos are needed. If you'd like to create a Rekapi animation and share it, please tweet it to @jeremyckahn.</comment>


Stripe for female founders has invited you to join Stripe Atlas - <AUTHOR> https://atlas.stripe.com/invite/atlasfemalefounders <comment><USER2> Since the offer is actually open to "anyone", I will suggest the title of the piece is more intended to say something like "Yes, even you women! The word _anyone_ is not code for _any white male with SV connections_. Honest!"

A lot of underrepresented people know that generic invitations don't really mean they are also invited. It's really only open to the existing in-crowd. As a woman who gets a lot of reactions that suggest to me that women are not supposed to so much as initiate conversations with men, I can kind of understand the logic here.

Having been burned by an extremely toxic classist group where, no, the rules absolutely are not the same for "the wrong kind of people" \-- by which we mean poor people (in this case, though they also do really shitty things to anyone who can't somehow establish in-group standing) -- I can understand why a lot of members of underprivileged groups err on the side of "They don't really mean _me_ when they say _anyone_ / _everyone._ "

My mind doesn't work that way. I generally take folks at their word, even when I know they may not really mean it -- and recently got banned from a forum for doing so because they were full of shit and didn't mean any of the high minded BS that came out of their lying mouths. I'm willing to live with that.

But I'm also very well aware that if you get that result often enough, shunning can mean you de facto have no income at all, there is no place for you to go, etc. It can be essentially a death sentence, and I don't mean metaphorically. I mean literally.

I don't know what the fix is. I'm not really all that crazy about the framing of this promo. But my suspicion is that is the real impetus here -- to make sure women don't feel that the subtext is "Not really _you_ , though we say _anyone_."

And, honestly, I don't have a better answer, so I'm not going to dog them for it.

<comment><USER3> Thank you for sharing your perspective. It's sad (but somewhat unsurprising at this point) that in a discussion about gender, the only post recognizably written by a woman is at the bottom of the page.

</comment></comment><comment><USER4> Looks like this post is angering some people so I will mention it looks like the promo is regardless of gender? Aside from the header "Stripe for female founders has invited you to join Stripe Atlas." there is no suggestion that gender is a limiting factor for the discount.

<comment><USER5> What makes it "for female founders"?

</comment></comment><comment><USER6> If you read the page carefully, they will waive the fee for anyone that uses the link. Assumption is they will be generally pushing this out via marketing channels that target women. Regardless, its a very nice thing for them to do!

</comment><comment><USER7> I get the intent here and applaud encouraging female participation and equality, but this is pretty much just discrimination based on sex.

<comment><USER8> People who immediately shout about something being unfair when they're the ones who aren't benefitting but don't say anything at all when they do really bugs me. It's just plain selfishness.

Fortunately I'm sure the people commenting here stand up to all discrimination and not just the things affect them.

<comment><USER9> When do men unfairly benefit from things in the tech industry? Can you show something _specific_ , that _isn 't_ a strong assumption of invisible discrimination on the basis of statistically differing outcomes?

Cuz I don't recall encountering any "men in tech" events, or investment funds that invest only in men, or efforts to encourage white boys to study computers.

<comment><USER10> I'm going to reframe those questions.

Why are there no "men in tech" events? Why are no efforts made to encourage white guys to study compsci?

After all, if there's a genuine need for them, I would strongly expect them to exist.

<comment><USER9> Because men in software don't agitate for them in the same way (some) women do.

But in other fields sometimes such events are organised, to encourage men into female-dominated jobs. Guess who comes out of the woodwork to attack them:

[https://www.theguardian.com/australia- news/2017/feb/08/sydne...](https://www.theguardian.com/australia- news/2017/feb/08/sydney-university-under-fire-for-vet-scholarship-giving- preference-to-males?CMP=share_btn_fb)

 _The University of Sydney is under fire for a new scholarship of nearly $30,000 that gives preference to male applicants, with the head of the scholarships office likening it to grants that "discriminate" against students who are not Aboriginal._

...

 _"The way I think about it, affirmative action should only apply to people who have structural barriers to receiving an education – that's what the exemption in discrimination law is about, so you can procure particular benefits for women in Stem [science, technology, engineering and mathematics], Aboriginal students and so on," Grant said. "It's not for further advantaging men. It's really quite bizarre."_

</comment></comment></comment></comment></comment><comment><USER11> Interested to know how this can be legal (much as I support greater balance)

<comment><USER11> Although the text does seem to say "anyone" so maybe it's just promoted as for women but actually open to all (avoiding discrimination rules?)

</comment></comment><comment><USER12> Amazed nobody read the offer before commenting. I guess women are a subset of anyone lol

</comment><comment><USER13> To end these discussions I will mention the following.

I contacted the Stripe Atlas team about this offer and as they say, if they read the website, it refers to the offer is only for women (but it is not the case), the offer is open to any person / gender that wants take advantage of it, they only put "For women" to continue promoting in which more founders are united to the emprendimiento of this decade.

For example, I just got the offer as a man, they did not charge me the $ 500 fee, so I understand that everything is correct.

Do not take everything as literal, one thing is what the web says and another is what they really offer, anyone can be wrong.

</comment><comment><USER14> It strikes me that it's rare that you hear an outcry about things being "marketed specifically to women" unless those things are ones that have traditionally been the domain of men. If an offer about makeup or diapers or Zumba class was clearly targeted at women, or even jobs that orient around similar themes, my guess is that it wouldn't merit much of an outcry on HN.

<comment><USER15> There's totally an outcry over "shrink it and pink it" as a marketing strategy. But, that's not what you were getting at, and indeed, you won't see much fuss about "shrink it and pink it" on HN.

</comment></comment><comment><USER16> This is great. I was just talking yesterday with my fiance about us needing to use stripe atlas yo open a company for our new side business!

</comment><comment><USER17> I do not understand why Stripe choose a headline that does partially cover the content of the article. In a sexist, but politically correct way. I also don't understand why comments about this being sexist get flagged. Finally, I wonder why the moderators changed the original HN headline to the same headline that Stripe uses. Isn't it HN policy that headlines that seems clickbaity or wrong get changed by the moderators, so that they become more factual and understated?

Anyway, great move from Stripe. Seems that they want remove barriers for starting and running a company, which is good for the creation of wealth and jobs. Be it Stripe Atlas, the card business, Indiehackers or the publishing company. Al those newly founded companies are also target customers for Stripe. Which is completely ok and speaks of good common business sense!

</comment><comment><USER18> How is this not sexism? Are women somehow less capable than men and need services handed to them in order to be successful? I don't think that's the case and I'm surprised Stripe appears to!

<comment><USER19> [https://news.ycombinator.com/item?id=17773057](https://news.ycombinator.com/item?id=17773057)

</comment></comment><comment><USER20> You know what would have been a much better move?

Stripe Atlas waives the one-time $500 company formation fee for everyone.

Stripe could then generate back the $500 in credit card processing fees by bolstering those startups, which wouldn't have otherwise existed.

Edit: I see where the confusion is.

The title is: "Stripe for female founders has invited you to join Stripe Atlas."

That's the reason for the reaction.

However, at the bottom.

"Stripe Atlas will waive the one-time $500 company formation fee for anyone that uses the link below by October 15th."

I applaud this. The copy should have been read a bit more carefully!

Although this article has been flagged. I would welcome clarification by Stripe!

<comment><USER21> that seems to be exactly what they're doing

</comment></comment><comment><USER22> Incorrect title.

</comment><comment><USER23> So that's how equality looks like?

<comment><USER24> Yes, that's how equality of outcome works. While equality of opportunity ..

<comment><USER25> Why is it based on gender and not financial ressources though? I'm fairly sure there are women who can afford to pay $500 for this service and men who can't, sounds like yet another unnecessary divisive PR move that no one needs right now.

<comment><USER24> You should see Medical Doctor acceptance criteria based on race (white vs black vs asian).

</comment></comment></comment></comment><comment><USER24> Is there any field AT ALL where males are underprivileged and they are somehow helped compared to females ?

<comment><USER26> Yes, nursing.

<comment><USER24> How are males helped with easier stuff on nursing compared to females ??

<comment><USER27> "Men offered a £3,000 sweetener to induce them to train as nurses" \- [https://www.telegraph.co.uk/news/2017/08/18/men- offered-3000...](https://www.telegraph.co.uk/news/2017/08/18/men- offered-3000-sweetener-induce-train-nurses/)

<comment><USER28> Ah, there's an offer. And it sounds pretty sweet. Then I went to the article and it says that it is a £30,000 fund. So that's enough for 10 male nurses :/

<comment><USER29> Good for them.

</comment></comment></comment></comment></comment></comment><comment><USER30> Are female less represented than, say, gay people? Are they less represented than, say, trans-black-woman or a non-binary-gender person.

Shouldn't we rise above and instead of helping minorities, just help/accept "everyone" already. A side benefit is to remind them that there is no such thing as "minority" and they are regular persons. And that no particular person no matter what his gender/color/religion is still a person and welcome.

And is it actually legal to give woman an unfair advantage? Or advertise capitalizing on it (I'm aware the offer is open to anyone).

</comment><comment><USER31> This is sexist. They should also allow Introverted Males WithOut Rich Parents to form a company for free. It is very difficult for an IMWORPs to start a company and raise funding these days. How many IMWORP CEOs are there these days? Probably close to 0. The worst part is that people make no distinction between IMWORP and EMWRPs even though we're the opposite.

</comment><comment><USER32> Does this apply to those that self-identify as female if there is a dollar in it?

</comment><comment><USER33> Inequality against man! Stripe wants to earn brownie points via hacker news. Not Good.

</comment><comment><USER34> "Form your new company as either an LLC or C Corporation in Delaware." \- Isn't Delaware the new patent troll capital. Why would I want to start a company there?

"Stripe Atlas will waive the one-time $500 company formation fee for anyone that uses the link below by October 15th." \- Not just females? Otherwise it could be considered discrimination.

<comment><USER35> Delaware has been advantageous for corporations for years for various legal and tax purposes, this isn't new.</comment></comment>


Making Games in Lisp with Hypergiant and Chicken Scheme - <AUTHOR> http://alex-charlton.com/posts/Prototype_to_polish_Making_games_in_CHICKEN_Scheme_with_Hypergiant/ <comment><USER2> I love Chicken Scheme, so this is great to see. Note that this article is from 2015.

Chicken Scheme recently received a version 5 release, so please be aware that this article focuses on Chicken 4, as I do not believe Hypergiant has been ported to Chicken 5 yet.

As an aside, it's a shame the footnotes render over the text for me in Firefox.

</comment><comment><USER3> I checked out hypergiant / chicken scheme a year or so ago - and was unable to get certain examples compiling / running on macOS.

While I'd love to play more with / learn more scheme - it's too niche of a language these days even for me (someone that writes a lot of Nim).

The scheme community seems to be very small to begin with, and then you factor in all the implementations - it's worse than the Common Lisp scene.

I do love the simplicity of the language and how elegant scheme code can look - and chicken / guile seem to be very well suited for game development.

I feel like I'd be trading a larger community for a smaller one at this point - and that's saying something, coming from a Nim user.

</comment><comment><USER4> A nice thing about Lisp (that is harder to achieve in other languages) is that you can make the text of your program look like it is written in a declarative rather than in an imperative (or a functional) language. (I think that's what is meant when they say that Lisp is perfect for creating DSLs.)

<comment><USER5> Harder in other languages except Forth. While creating DSLs is easy enough in Lisp, Forth is more of a DSL construction kit than a programming language. Which is why there are roughly as many dialects as implementations.

<comment><USER6> Forth... so alluring, yet so scary. I am afraid doing it will make me do great things no one else can understand and maintain. :)

<comment><USER5> I've been working on one of my own that attempts to bridge some of the gaps between Forth and the rest of the world, feel free to take her out for a spin:

[https://gitlab.com/sifoo/snigl](https://gitlab.com/sifoo/snigl)

<comment><USER7> I presume you would know of factor, curious what you think of it.

<comment><USER5> Sure, I've played around with it; still too complex and too static due to being natively compiled.

I've mostly given up on the idea of driving applications from a higher level language, I much prefer having C as a foundation and then embedding a more dynamic language that I have full control over. I like to call it reverse FFI :)

<comment><USER7> So Guile, Lush, Lua, Tcl would be the other likely candidates. I do use Python but more as a remote control over C.

<comment><USER5> Yep, more or less. Though if you flip through Snigl's README, there's already plenty in there that these languages will never be able to do.

I used to do that in Common Lisp, which has the only FFI I've come across that's even nicer than Python's. But it's backwards; once you're in a high level language, it's inconvenient and expensive to reach down.

It makes a lot more sense to me to drive the whole process from C; not only do you have direct access to C; you also get to control the embedded world from the outside, which is about as meta as it gets.

<comment><USER7> Just in case my comment came out as "why are you working on Snigl ?" ... I was thinking aloud on what are some of the other languages that you might like. Snigl sounds pretty cool and fun.

<comment><USER5> No harm done; I'm doing this with or without, because it has to be done.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I wish Chicken Scheme could be ported to Windows without the Posix dependencies. I run it on my Linux box, but unfortunately, work is all Windows. I have had years of frustration with Cygwin and MinGW or MSYS to run such things. I use Red [1] now, which is homoiconic like Lisp, has a great parser, and runs on all platforms with an executable under 1 MB.

[1] [https://www.red-lang.org/](https://www.red-lang.org/)

<comment><USER9> You _use_ Red? Not just play with it? Could you share some details?

As for posix subsystems on windows, they're indeed painful. But the new Linux emulation layer is quite good - in some cases it might be a viable option.

<comment><USER8> Use for me is writing small utilities for work. I am not a programmer, but I work in entertainment engineering, and Red has proven useful for making all sorts of utilities to get my job done. I am currently trying to use Red to create the GUI and glue some other utilities I use together. I hope to get better at it to create full applications. Amazing for its size, and I've always loved Lisp and Forth.

</comment></comment></comment><comment><USER10> I've been using Chicken Scheme a lot and I find it to be awesome. I wish Hypergiant was supported in version 5.

</comment><comment><USER11> Surprise to see a Go board displayed. But given Alpha Go, is Lisp is still relevant or is there a way for chicken to call say leela zero?</comment>


Ask HN: Document Templates for Consultants? - <AUTHOR> Following the Ask HN on becoming a consultant I wonder if anyone has templates to link to or share? Contracts, proposal and Statement of Work are top of mind unless there are others as well? <comment><USER2> No document is as valuable as strong relationships.</comment>