laarcnew | comments | discord | tags | ask | show | place | submit | rain1's favoriteslogin

Awesome! This takes care of one of the prerequisites for https://www.laarc.io/item?id=230#313 :)

-----


That was a great idea. QuiteRSS is my new favorite reader.

https://www.laarc.io/newcomments and https://www.laarc.io/ now works with QuiteRSS.

It'd be easy to add feeds for each tag, too. Something like /l/music.rss

-----


Oh yeah, that was a slip. I've clearly spent more time posting links on Lobsters than HN recently. Yeah, Markdown or a HTML subset would be nice. Embedding the links is an advantage Lobsters has over HN since it reduces clutter.

-----


Thank you!

-----


I've been laid up with a fever, and I read this today right after finishing "Lying in Wait" by Liz Nugent (https://www.amazon.com/Lying-Wait-Liz-Nugent/dp/1844883639) and it made for a piquant pairing. Thank you!

-----


My `tangle` currently inserts `#line` directives, which helps with error messages. But inserting them into the git history is noisy. Another reason to create the repo from scratch on demand, using it only for browsing convenience, not as a source of truth.

-----


"which is something applications don't do outside smalltalk-land."

I thought Lisp's could do live updates. Outside Lisp and Smalltalk, what about apps with Lua scripting like [Luakit](https://github.com/luakit/luakit)?

-----

2 points by enkiv2 177 days ago

For any dynamic language with a REPL, you can expose the language & make it so live modification can be done. GUI toolkits don't tend to expose the language by default, & applications don't tend to go to the effort to expose them themselves (or design their internal structures to be amenable to live-editing by non-programmers as opposed to modification during a normal development cycle).

It's not a problem of missing features generally (though sometimes it is -- like if a language, by default, loses the original source after bytecode compilation, & the compilation step can't be hooked to keep that source around), but of UI (though a whole host of unusual language features can make providing a reasonable UI to do this a lot easier -- like having an image-based system and having that image versioned internally).

Back in high school, I wrote a system intended for exposing live tcl scripting to a Tk-based set of widgets, as part of a 'desktop environment'. Doing such a thing is easy, if you don't mind doing it badly, even with a language & framework like tcl+tk that isn't really intended to support it.

Scriptability is, I think, a different (related but less interesting) version of this. Rarely is the whole application really scriptable -- it's unusual to have an application that can be turned into functionally an entirely different application through the exposed scripting API without a great deal of knowledge and effort (greater than the knowledge & effort necessary to write the thing from scratch in a normal environment); and then, scripting normally operates in the same way as a normal build process (wherein you edit files on the filesystem with your text editor & force a reload), which ultimately means unfamiliar tooling to non-technical users & no support for built-in documentation.

I think the article here describes a spectrum of end-user-programmability where the far end is what I termed 'composable UI' -- stuff that looks like smalltalk environments, in that the programming environment is one pop-up menu away from any widget, with full built-in documentation, and where a non-programmer can stumble into it accidentally & be glad they did because it let them solve their problem.

-----


> Below you will find a Redis clone, pydis, written in < 250 lines of idiomatic Python code, providing a subset of redis' functionality for which there are official benchmarks.

> Briefly, pydis is ~60% as fast as Redis measured in number operations per second.

In otherwords it's 40% slower than Redis and doesn't need to account for probably half of the things redis needs to account for.

> pydis is an experiment to disprove some of the falsehoods about performance and optimisation regarding software and interpreted languages in particular.

I don't think the results of this experiment proves anything accept that interpreted code will always be somewhat slower, which is pretty obvious.

-----


Do you have some irc or chat as well?

-----


Created a public Slack workspace. Feel free to join. Info here:

https://www.256kilobytes.com/content/show/4479/256-kilobytes-public-slack-workspace-server

-----


That's a good idea --

The site admins are in a private Slack chat. Will look into an IRC or Discord or similar. Will drop a post on the site if/when a public chat is live.

-----


Not a bad policy:

Note that, as they say, "I don't have fucking brain damage; if you send us recommendations to pin posts with blatant ads for garbage affiliate sites, I will personally come to your house and stab you in the dick."

Do mention when your Discord/IRC goes live.

-----


7 Reasons Why You Should {Buy|Purchase} {Cheap|Inexpensive} {Cialis|Viagra} {Online|Today|Right Now}

And will let you know about Discord/IRC.

-----


sounds great how many users are you at atm?

-----


Just checked the users page a minute ago (https://www.256kilobytes.com/users/index?page=9) and we're at 83 total accounts (including a few spam/test accounts).

-----


Not to bad how long have you been at it?

-----


First post went live the start of December.

-----

3 points by shawn 217 days ago

Ditto for laarc.

-----


(Speaking of [foo](https://example.com) syntax, I'm planning to add markdown support for that. Stay tuned!)

-----


Oh yeah, that was a slip. I've clearly spent more time posting links on Lobsters than HN recently. Yeah, Markdown or a HTML subset would be nice. Embedding the links is an advantage Lobsters has over HN since it reduces clutter.

-----

More

Welcome | Guidelines | Bookmarklet | Feature Requests | Source | Contact | Twitter | Lists

RSS (stories) | RSS (comments)

Search: