d-mason's comments

d-mason | 4 months ago | on: How I turned Zig into my favorite language to write network programs in

I am working on a ~15K loc project in Zig and have been for over 3 years. Most times a new version comes out there is nothing to do. A half dozen times I've spent as long as half a day updating references to the standard library.

There have been 3 significant problems (2 of them LLVM changes that Zig hasn't adapted to) that have been multi-day frustrations.

We are currently holding at 0.15.1, partly because of the I/O changes (although we're not heavy users of I/O), and partly waiting for the native backend implementations to stabilize.

All that said, we remain very happy with the choice of Zig - it has so many advantages over C/C++ and even (for our application) Rust (we have about 3K LOC in our original Rust implementation).

Is Zig fully mature? Certainly not! Is it mature enough to be highly productive? Certainly!

d-mason | 3 years ago | on: Lisp in Space

I would say the same thing (or more exactly, the dual) from a Smalltalk perspective: I just want to send a message to an object, I shouldn't have to figure out what function to call or what to parenthesize. The problem people get into with OO (particularly Java, C#, C++) is thinking in terms of method-function calls rather than message sends.

Although I do like Lisp generics - I did a bunch of programming in rscheme many years ago, and really liked it.

d-mason | 4 years ago | on: Pharo 9

Pharo, like its siblings Cuis, Squeak, and NewSpeak runs on a VM called Open Smalltalk. It is written in a stylized version of Smalltalk so can be debugged with the tandard Smalltalk tools (i.e. you can have the modified VM you're working on load and run an image - but your VM is running in a debugger!)

Then when you're happy with your revised VM, you can spit out portable C code, compile it, and BAM you've got a production VM! Most plug-ins and primitives are also written in the Smalltalk subset (called SLANG), so they will likely be similarly portable.

There is also an FFI for interfacing beyond the standard model.

d-mason | 7 years ago | on: Pharo 7.0 released

Development is entirely via the most integrated GUI you've ever experienced. It runs on MacOS, Windows, and Linux.

For deployment, you can run it headless.

You can also deploy as Javascript for Node/Browsers via a tool called PharoJS (http://pharojs.org - full disclosure, I'm one of the principals of PharoJS), but it's a work in progress (with a Slack workspace to support it).

GNU Smalltalk can deploy to a standard executable, so you could do most development in Pharo, and then switch to GNU Smalltalk, but you'd lose the fabulous IDE.

d-mason | 7 years ago | on: Pharo 7.0 released

One of the key words in that statement was "actively developed". Cincom, Instantiations, and GemTalk have some great people working on them, but Pharo7 had 75 different people contributing - including probably almost as many full-time people as the commercial developers (maybe more).

d-mason | 7 years ago | on: Pharo 7.0 released

The small size of methods is a feature, not a bug :-).

And this partly explains why the lack of [your favourite editor] bindings isn't so important. You don't typically spend as much time as you're used to typing in code - and make progress faster as a result - counter-intuitive as that may sound. The integration and the debugger are most of the reason why.

d-mason | 7 years ago | on: Pharo 7.0 released

It is an alien world.... but a better one by most measures.

I come from Emacs (20+ years when I first encountered the Smalltalk IDE), and find aspects of code editing irritating sometimes, but the overall value of the IDE more than pays for that irritation.

One of the coolest things is TDD carried to an extreme level. I build my test, and it fails because there's no such method, so I get a debug window and tell it to create the method... then I fill in the contents and click proceed... and picks up where it left off! It either works, or I'm back in a debug window fixing what failed. Total time from thinking of a test to working code, often less than 5-10 minutes.

page 1