peterkelly

Pro Git: https://git-scm.com/book/en/v2

The Rust Programming Language: https://doc.rust-lang.org/book/ (the Rust standard library also has very comprehensive documentation)

Cocoa architecture: https://developer.apple.com/library/archive/documentation/Co...

Python: https://docs.python.org/3/tutorial/index.html (also pretty good standard library docs)

Scheme R5RS: https://standards.scheme.org/official/r5rs.pdf

Racket: https://docs.racket-lang.org/

SQLite: https://www.sqlite.org/docs.html

FreeBSD: https://docs.freebsd.org/en/books/handbook/

Some of us never left :)

Usability has taken a nosedive with the rise of web apps. Every company wants to have their own special branding in the form of a "design system", and there's a whole industry of designers coming up with different non-standard ways to do things.

Pope Benedict passed away on December 31 2022.

The article you linked to is titled "Former pope Benedict XVI reported to be seriously ill" and predates his death by more than two years.

Damn, I was joking in my original comment, but yep there it is.

    In-App Purchases
    Roland Cloud Core Year $29.99
    Roland Cloud Core Month $2.99

https://www.roland.com/global/categories/roland_cloud/

"Roland Cloud is an evolving cloud-based suite of software synthesizers, drum machines, and sampled instruments for modern creators."

It's not hard to predict how that's likely to pan out in the coming years.

I recently saw a second hand Roland AT-900 organ for sale near me (https://www.youtube.com/watch?v=Mfm_AYqI1No). I'm tempted. The fact that comes with all it's sound and functionality built-in and doesn't have any internet connectivity which can be used to disable said features after my subscription expires makes it more compelling.

Finally, an internet connected piano.

I can't wait until I get prompted to install updates while playing, have to pay a subscription fee to use the sustain pedal, and have the instrument become non-functional 15 years after purchase once the manufacturer finds the service is no longer profitable and decommissions its server.

You could make the same argument for the the organists themselves though - theatre organs were designed to take the place of an entire orchestra, needing only one musician instead of 30.

I don't expect this will happen. There's a good reason why floppy disks are no longer used, but I would be surprised if physical books ever go away.

Personally, as much as I like the convenience of digital books, there's nothing quite like the reading experience that comes with a printed physical book.

10x engineers create themselves.

All I can do is express my sympathy to those affected. None of you deserved to be treated like this.

I was a contributor to a little pair of libraries called KHTML and KJS, a HTML renderer and JavaScript interpreter. Joined about a year into the project and while I didn't lay the foundations I helped improve the DOM and JS support a fair bit.

People I respected told me I was wasting my time because Internet Explorer was the de-facto standard and the idea of a new browser engine becoming prominent was fantasy.

Then Apple decided they wanted do a browser and looked around at what open source engines were available they could use as a starting point. Thus was born WebKit [1].

I consistently ignore anyone who tells me I shouldn't try something because it's "too hard" or "nobody will use it". Most of the time they turn out to be right. But not always.

[1] https://marc.info/?l=kfm-devel&m=104197104218786&w=2

Edit: Here's an interesting presentation by Lars Knoll and George Staikos on the history of the project: https://www.youtube.com/watch?v=Tldf1rT0Rn0

So what? The US has less than 5% of the global population. Pretending the other 95% of the world is "irrelevant" seems odd.

Yes.

I personally find Rust's way of doing things superior (for reasons masklinn mentioned in his comment), but it's basically the same principle, just realised in a different way.

masklinn already made lots of good points. I'd add that panics in Rust are for intended for non-recoverable errors (like memory allocation failures, out-of-bounds access) and under most use cases are equivalent to abort(). There are mechanisms to catch panics in Rust, but the docs state:

"It is not recommended to use this function for a general try/catch mechanism. The Result type is more appropriate to use for functions that can fail on a regular basis. Additionally, this function is not guaranteed to catch all panics, see the “Notes” section below."

> atomic transactions that are undone when something fails

This is exactly what many business apps do frequently, through the use of database transactions.

[1] https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

Exceptions are an anti-pattern. If a function can encounter an error, it should expose this fact through its interface (specifically its return type).

For example, Rust has a Result type [1], so this function would return Result<Item, ItemNotFound>. This forces the caller to think about what to do in case of an error and specify what should happen.

[1] https://doc.rust-lang.org/std/result/index.html

> where EM wants to take Twitter

based on his actions to date, the only explanation I can think of is he wants to destroy it

Agreed. Also btw there's a typo in your link. It should be https://fredgrott.medium.com/ (there was an extra o in com)

Academia is an option. I was in a similar situation to you early on in my career and decided I wasn't happy in industry, and decided to enroll in grad school. I ended up teaching for a couple of years and found that I really enjoyed it. And the kind of work you do on research projects is very different from that of the corporate world - you can focus on longer-term things with less immediate results, the work itself can be super interesting, and there are always lots of interesting people around in a university environment.

Academia has its downsides however - the job market is brutally competitive, it can be very hard to get research funding, and you can spend a lot of your time writing grant applications. There's also admin duties to take on which can eat up more time. It also has bureaucracy and since it's an institution comprised of people, is not immune from many of the interpersonal conflicts that occur in the corporate world.

I'm speaking from the Australian perspective here, but in my country the universities also decided to sell out and take in lots of international students who have $$$ but lack sufficient background knowledge and motivation, and lecturers are forced by the universities to let students pass who haven't demonstrated sufficient competency. I was asked to change marks on a course to reflect the number of students who the university wanted to pass, not how many were actually worthy of it, which I felt was unethical. Because of all these issues I decided academia wasn't for me so as soon as I had my PhD I got out. I still miss the actual core teaching part though, as it's one of the most enjoyable things I've done.

So I ended back in industry where I'm back to building software, but in a role that lets me use what I learnt in grad school and is thus more interesting than just building basic web/CRUD apps. Not all companies are bad, and I've been lucky enough to find an employer where the bureaucracy is minimal and my manager makes sure I'm pretty well isolated from the things which get in the way of actual work. There are good companies out there, but it takes a certain amount of luck to end up in one with a healthy culture.

One other piece of advice I have is that if you're from a rich western country, move to somewhere with a lower cost of living and work remotely. I relocated from Australia to Thailand and it approximately quadrupled my spending power. This gave me the freedom to be able to take time off from my job more often to do other things like work on hobby projects, and while I don't currently take advantage of this freedom much it's nice to know its there. Depending on who you're working for, you might be able to negotiate a part time gig, or if contracting do six months on, six months off or something like that.

Oh, and on going it alone and trying to be an indie dev: this can be super tough if you don't have good business and marketing skills. I tried this and failed. Others have made it work, but it's definitely not easy.

Our industry was once capable of building entire operating systems that ran in significantly less than that.

It's easier to get forgiveness than permission

Why does meta have 10 million lines of code just for Android?

Next article will be about how the inventory capacity of ancient warriors is grossly misrepresented.

OP said they already have a working system. How well it works remains to be seen, until it's publicly available.

On what basis do you assume he/she has not succeeded without even having seen their work?

Seems like it might have been a good idea to discuss this "art project" with the Apple store in question before proceeding.

That was my favorite part :)

Since the talk was already posted yesterday, here's another great related video that is well worth watching: Dan Ingalls demonstrating Smalltalk 76 on a restored Xerox Alto.

https://www.youtube.com/watch?v=uknEhXyZgsg

This is where it all started and it's truly amazing what they achieved on such limited hardware.

The ideas he's promoting aren't new, and in fact predate even the NES.

They date back to Smalltalk, which was created at Xerox PARC in the 1970s: https://www.youtube.com/watch?v=uknEhXyZgsg

Agreed on static type checking - I also consider it extremely important. However I don't see it as being incompatible with the philosophy of live programming. Smalltalk relies a great deal on dynamism, but I believe it would be possible to create a language and environment that both enforces static typing and supports live programming + persistence. It's an open research problem though.

It's no different to someone hacking in and then copying over a modified executable, changing entries in the database, or attaching to a running process using gdb to inject code.

You still need proper access control.

Excellent question.

The way I see it, there's two scenarios where this approach can be useful, which I'll address separately.

The first is for local development. When iterating on a solution to a problem, it can be a hassle to restart the program from the beginning and incur the time penalty to get to the part you're modifying in order to test it. This can include not just compile times, but also program startup, loading in necessary data, and going through a series of steps either in a UI or via API calls to get the system into a state where it's about to trigger the functionality you're working on and want to test.

For example, I'm currently working on a business workflow that has a bunch of steps that require someone to fill in several forms, and things happen after each of those. When I'm working on stage 5 of that process, testing it involves repeating all the actions necessary to go through steps 1, 2, 3, and 4. Yes, it's possible with extra effort to automate this, or to create mock state that can be used to jump directly to step 5 on launch, but that's just a manual substitute for what a live programming environment gives you automatically. A similar situation occurs in game development; you don't want to play through half the game every time you want to get to a particular part where you've changed how a particular enemy acts.

The second scenario is production. You're correct that it's important to only deploy code that's undergone proper testing and review, has a known version, and is reproducible. However this is orthogonal to the use of a live programming environment. With the latter, you wouldn't just have developers interacting with it in an ad-hoc fashion (just as you wouldn't have developers directly modifying python scripts on a production server). Instead, the ability to modify running programs can be used as a deployment mechanism. Once a set of changes has been made in a local development environment, undergone testing, and is deemed ready for deployment, the same mechanisms for updating running code that are used for development purposes can be used as a way of deploying code. And in production, the fact that you don't need to restart the process means you can avoid downtime.

As far as deployment and versioning is concerned, you can think of it as being a similar to how you would do those things for a server based on CGI scripts or similar (e.g. PHP) where every time a request is served, the file is read from disk and executed. The difference there is that all state has to live in a database, so if you have long-running processes e.g. business workflows that span days or weeks, all state transitions/control flow has to be managed manually, rather than using language features like sequencing, iteration, and function calls. With a live programming environment that supports persistence (meaning that execution state is stored in a file or database in a manner transparent to the programmer), deployment consists of adding/updating a set of objects in the data store, rather than copying a set of files to a particular location.

An example of a system that supports runtime code updates is Erlang, though it is not persistent. An example of a system that is persistent is Ethereum, though that doesn't support runtime code updates. Smalltalk and its variants support both.

Auditability can be supported by ensuring all changes to code or runtime state are made through transactions.