Hacker News new | past | comments | ask | show | jobs | submit | pjmlp's comments login

Depends, Windows Store and the respective sandbox is a thing.

They already kind of did, I only install PC games via the Windows store.

And then their MMO/MMORPG server gets p0wned, with everyone taking advantage of extra virtual money, adding assets to their characters for free and auto aiming packet correction.

> Does anyone know any good static analysers other than gcc's or clang's?

Visual C++ as well, because since the XP SP2 issues, Microsoft has come up with SAL, which you can also use on your own code,


Then specialized tooling just for this purpose, just two examples,



Regarding C, I would really like some kind of -fsafe-mode, but I guess we need to contend with -Wall -Werror and -fanalyse.

From my MS-DOS/Speccy programming days 400KB is a lot, no need to make use of the OS, if one can avoid it.

Why use the OS then? Just do bare metal runtime like we used to do on MS-DOS days.

Well the ESP-IDF is freeRTOS based, so: threads. But have fun re-inventing the SDK I guess?

Exactly, FreeRTOS makes it trivial to spin up 20 threads... who was doing that with MS-DOS?

You wouldn't, because the whole point of bare metal is to ignore the OS and use directly the BIOS and hardware.

And regarding threads, we would use cooperative concurrency, and also take ownership of the timer interrupt.

Anything is easy when there is an abstraction implemented as library.

Games and demoscene tricks.

What about botnet operators? This would give them a hard time if they have to hack each device specifically instead of recycling old linux vulnerabilities wholesale. The whole IoT industry is strongly committed to make devices available to botnet operators, indeed this looks like the main function, the function on the packaging usually works poorly and is likely just there to convince punters to install the botnet relays and pay for the hardware and power.


The ESP-IDF environment is based off of FreeRTOS, not Linux. It's essentially a threading library, not so much an OS.

Lisp and Clojure have CLOS, which is more powerful than what most people know as OOP.

ML, depending on the flavour gets pretty how one combines functors, aka generic modules, which is similar to component based programming like COM, or just plain objects as in OCaml.

Now the immutability isn't as hard to adapt to as one may think.

Clojure has CLOS? That would be new.

Fair enough, I was over simplifying, still it has a nice subset of it.

What is this 'subset'? CLOS is based around class&inhertance&mutability + generic function dispatch over classes. Spiritually Clojure wants to avoid OOP, where CLOS is a full object system with an optional meta-layer.

I know you are a Lisp expert with a deep knowledge of its eco-system, but trying to downplay the existence of multiple dispatch and protocols doesn't help.

Also I bet that The Art of Metaobject Protocol reference implementation can be ported into Clojure without major issues.

The Art of the Metaobject Protocol has no 'protocol reference implementation'. Neither CLOS nor AMOP supports explicit protocols. Explicit protocols are a feature of Clojure.


"A protocol is a named set of named methods and their signatures"

Such protocols are not a language feature of CLOS.

AMOP describes a 'Metaobject Protocol' (MOP) and has a tiny example implementation (called Closette). This is entirely different from what the 'protocols' feature does in Clojure. A 'protocol' in AMOP is informal.

What AMOP actually describes with its MOP, is a meta-level of meta-classes and generic functions, which implement large parts of CLOS itself. Such the classes, generic functions, methods, slot descriptors, etc. are CLOS objects themselves.

Clojure supports a form of multiple dispatch, but the dispatch mechanism is also very different from CLOS - for example it uses a dispatch method per generic function, selects one method and has no idea of a next method. CLOS for example uses a built-in dispatch mechanism, multiple class-based dispatch hierarchies for multiple arguments, using a set of methods which are selected based on the class hierarchy.


Typically it is not a good idea if Clojure uses a name for a feature, to generally think that this is similar to a feature with a similar name in Common Lisp -> 'protocols' and 'meta-object protocol' are two very different things.

Porting the CLOS MOP to Clojure would be possible, when one first implements CLOS in Clojure. Otherwise it makes very little sense, since Clojure does not by default support the (older) view of object-oriented programming of CLOS. Something which the Clojure designer thought of a feature: getting rid of things like mutable objects, class based inheritance, class-based OO, etc.

That is no different than in languages like D or Go, the runtime comes along.

Actually no, because on the release CD of Common Language Runtime, and the alphas and betas that preceded it, Microsoft collaborated with several companies and universities to have various languages available at lunch date.

Many of which did have a REPL.

Also the dynamic language runtime originally designed for Iron languages, Python and Ruby, precedes F#.

Can vouch for it, it is my favourite option on the Java side, no need to try track down ORMs performance issues.

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