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

I've recently built Linux dev environment for Amiga and documented the process in a form of a blog post.


This is quite tone deaf - demoscene stands for creativity and resource constraint, and using ai cancels both in favor of resource intensive cognitive offload


Not knowing the scene and only what I took from the article - it’s precisely this. There is a reverence towards human labour and effort that affords relaxing what are generally accepted social contracts in other areas (e.g. copying). It’s a very interesting social construct where the self-policing is in a very specific are whilst other areas are forgiven.


to be honest I feel much more comfortable with git -- muscle memory, magit etc., but fossil is much more appealing when you look at the underlying model and how it bundles wiki and issues along with the repository; that's why I'm starting as of late all my solo projects with fossil repo.


CL enables many paradigms of programming, including functional one and imperative. Currently the most popular way of programming among CL programmers is OOP with CLOS.


There's also Guile Hoots compiling directly to WASM.


Btw, eval (ed "wecl.lisp") to see some interesting function definitions, like canvas or webgl access drafts.


Bytecodes compiler used in this build from repl is one-pass with very little optimizations, so it is not surprising. Natively compiled code is much faster.


Should it be possible to implement an optimization compiler? so that compiling the code in the web page produces results similar to ECL or sbcl?


With enough code - yes. But not right now. You may precompile to native though.


What a bunch of fud..

If you want to make mcclim progress faster then chip in with actual expertise instead of unfunded snarks.

ECL is a stable implementation with actual users, if you can point out existing problems then please report them.


ECL features native code and bytecodes vm for targets without incremental compilation support - both native and bytecode can be freely mixed at runtime.

That means that you may interactively use repl to call functions that were compiled ahead of time and to add new functions even on uncooperative targets.

After you've finished prototyping you may compile the finished library to native ahead of time.


This is just a test page. Today I've shared an information about an accepted grant proposal:

https://functional.cafe/@jackdaniel/114742776265318353

The work will go towards improving browser integration and porting to WASI.


Will this include some form of SLIME support?


I didn't plan explicitly for SLIME, but loading swank shouldn't be much of a problem. The missing piece would be a bridge between a websocket and tcp I think.


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

Search: