mdhughes

Which eggs? I'm on Mac, and in Chicken 5 currently, everything has "just worked". SDL required me to hit the SDL site for the frameworks, the rest I've used have had no external requirements.

I've never had a Windows, I'm a Mac nerd, but I'm looking into it for cross-platform binaries.

Option 1: MS has a Linux subsystem now. Problem solved, but maybe not customer-friendly.

Option 2: Cygwin probably works, I've seen John Cowan mention it in IRC.

Option 3: This somewhat messy process: https://wiki.call-cc.org/compiling-chicken-on-windows-xp-wit...

[Chicken Scheme](https://call-cc.org) is fast, makes native binaries, and has a giant library of "eggs" covering most of the SRFIs. It's R5RS working its way towards R7RS. I've been using it for my "Python but fast" code for the last year or so, and it's one of the best production languages I've ever had.

[Chez Scheme](https://scheme.com) is super fast, and has the best REPL I've ever seen, but can't easily make binaries, and has limited external libraries. It's R6RS, which I prefer, but in the event you find other Schemers to work with about half of them are going to be annoyed it's not R7RS.

I found Racket to be substantially slower to compile and at runtime, the library is weird and not what I expect of a Scheme, and DrRacket IDE has some annoying quirks (it destroys your REPL environment every time you edit & run source, which is just monstrous). It's really heavily designed around educational uses, not so much production, and with the "Racket 2" changes it's likely to fragment and chase off any serious users.

Learning one Scheme (with SICP, TSPL, etc.) gets you 95% of the way with any Scheme; not so much with the three major LISPs (CLISP, Clojure, Arc). You'll still spend half your time reading library docs and SRFIs, which is where they all differ.

With any Scheme or LISP, you're going to face opposition from soi-disant "programmers" who don't like to learn anything about programming, and managers who don't want to support anything that isn't in the last 5 buzzwords they've heard, but if you own your own project, it's pretty great.

I spend most of my time now in Chicken Scheme http://call-cc.org/ and it's very productive, has a ton of libraries ("eggs"), and makes nice, fast native binaries. Scheme's right on the edge of ascetic discipline and productive tooling, where so many languages are much too far either way.

Racket's weird, not quite a Scheme anymore, tons of libraries but they're often hard to use, and the object system infected too much of it. And performance is poor even with Chez underneath, there's just too much stuff on top. It's a better teaching tool with the tutorial sub-languages than a production language.

I can't work in CLISP, it's like scavenging a junkyard for parts where some work, some haven't for 30 years. Some people love that experience.

Strong typing (also in Typed Racket) isn't going to improve anything, but it's good for marketing to enterprise people.

Go ahead and invent some totally unique tool nobody's ever seen before. I'll wait. You, uh, you got one yet? No?

The point is to make your own version of a thing; it doesn't have to be one of those few I listed. To see that some other design or implementation doesn't satisfy you, and analyze why, and do it "right". You can only get that by writing something you can compare to something else.

If you do invent a thing for the first time—which you won't—it would be terrible. It'll take many iterations, your own or more likely someone else's. That's how Human tool-making works, from the first half-assed rubbing-sticks-together fire to nuclear weapons (the first Atomic Bomb was not the best…)

And to a certain extent, I don't consider people incapable/unwilling to do this "programmers". Merely typists.

Without the experience of making and supporting such tools, you'll never acquire wisdom, or many useful skills.

Thought.py is maybe my 4th note-taking system, simpler and more precisely what I needed than any previous. Practice makes perfect. Doing nothing makes nothing.

Why, so have I, and so has every other programmer on Earth.

https://mdhughes.tech/thoughtpy/

This has been mostly used as my engineering notebook, in lieu of stacks of Moleskines.

Simple command-line tool for editing and searching, a pipeline to any Markdown app for display, and DropBox for syncing, that's all I needed.

I could also use it on mobile with Pythonista, with some changes to get a DropBox path and open it in Editorial or Drafts, but so far just having the files is good enough.

My point is, every programmer should be capable of making certain basic tools of their own, such as note-taking, blogging, a calculator, and scripting languages.

I'm one of the people who kicked in for the Megatokyo visual novel kickstarter. Years later, no visible progress; I'm not even mad, I knew exactly what I was signing up for, which was supporting a comic that had slowed to almost non-updating, and maybe getting a thing someday.

New comics are still weekly to monthly, if that. I've completely forgotten the origin of the current catgirl plot, but possibly Ping (or the catgirl she's based on?) will finally do something, maybe in the next couple years? Who knows.

The guy who drew "Sad girl in snow" isn't going to be one of your super productive Jack Kirbys, he muddles along as best he can, like a lot of us.

Strongly disagree. VS Code is a corporate tool IDE, which is dull and awkward to use as just an editor, and binary spyware in it "phones home" to its users' masters in Redmond. It's exactly what an MSDN subscriber would like, but dire for anyone else.

Atom is fun. It's easy to configure in weird personal ways, get rid of parts you don't use, add your own plugins, change CSS as you like. There's an insane number of plugins and themes. It's like emacs but organized and nice.

So far the statements from project owners in public and on Slack have been that Atom 1 & 2 development continues full speed.

If it is "killed" we'll just fork it and run up a black flag.

Very simplistic and shallow list, but it's by Charles Petzold, noted Microsoft shill and bad tech book writer.

In '96, LISP (tail end of the AI winter regardless), Perl (half the WWW was Perl), Tcl (maybe a quarter of the WWW and telnet-based services were Tcl), awk, & Ada were quite common, and Smalltalk, RPG, REXX, & PL/1 were at least as common as COBOL. Python was still obscure but gaining ground. PHP had just been released like smallpox on a vulnerable population.

I had a laugh at Delphi being for people who hate Microsoft. Its actual virtue was good performance and safety in large programs, you bought Borland tools because you wanted to double your program's speed, not for ideology.

Slack is a poorly-written Electron app, and unfortunately it's the poster child for it.

Discord does more with a fraction of the resources, and is also Electron. Atom is a giant editor framework, and is still less heavy than Slack in normal use.

Electron can run quite reasonably when you aren't an idiot/under complex enterprise requirements which probably explains Slack's load.

Cross-platform is the key problem.

If I want to write a Mac-only app, I can do that in Objective-C/Cocoa, and be quite happy.

For Linux, native means fighting with primitive C and X11 or Gtk, etc., which I can do but I loathe it.

For Windows, I have no idea, C# maybe? I'd rather eat broken glass than install Windows and find[ed.] out.

So if I'm doing cross-platform, my current working choices are Electron, Java, FreePascal/Lazarus, or Scheme.

Electron's easy to build all three platforms on, performance is OK despite the bloated example of Slack.

Java would need to bundle the JRE everywhere, and I've been largely Java-clean for 10 years.

Lazarus is semi-broken on Mac currently, only 32-bit like stone age tools, Cocoa port is unfinished. Maybe they'll get their shit together someday, I like it when it works.

Scheme native binaries are hard and experimental, but getting better.

Using a WKWebView on Mac, then writing a completely different wrapper on Linux & Windows, is unacceptable for my uses.

So my actual shipping code is Electron.

This is using Python 2, which is end-of-lifed. Those bare print statements are gauche. Python does have a variable keyword, `global`.

While JavaScript can omit semicolons, it's an incredibly bad idea outside of console/Node REPL. In particular it'll merge adjacent closures or constants, and you'll have an incredible time trying to find that error. Semicolon everything.

The arrow function as ()=>{} is clearer and less likely to suck up adjacent terms.

There's no point in even showing C#, since it's just Java with the capitalization swapped. Go, as well, but at least it's slightly different.

OP should learn some languages which aren't just FORTRAN-with-C-syntax, like Scheme (or any LISP), Haskell, ML, etc.

You can actually run LUA scripts from chat, exactly the same way:

``` /script d("Hello") ```

But the PC/Mac ESO community tends to be older (rated M) and less gullible in chat. Gold-sellers got a cold reception and rapid bans.

I suspect that'd work on console players, who tend to be younger, if they had scripting and addons, which they do not.

I'm not hostile, riffing on a cartoon is what humans call "humor".

While I have no problem with "Scheme is Spock", I'd put Captain Pike in his beeping wheelchair in the CLISP slot, and Clojure is clearly Kirk: All but married to the Enterprise.

But whooo, there's some tactless stuff in those PHP and Forth slots. And Javascript's a Scotty-type lang now, it's for getting engineering done.

Right, Scheme is used and those uses are reflected in the spec(s). The minimalism of Scheme is what makes it easier to optimize, but that's not why it's alive.

If LISP users want their variant to stay alive as well, they need to follow that model of actually using it and documenting how it's used.

Vengeful LISP zombies gonna downvote, of course, because they're bad people.

Scheme moves forward because it's not a rotting corpse as LISP is pictured in that cartoon, it's a still-living language. Scheme's not admired for its purity and historic role, but because it's useful and fast. The R6RS/R7RS arguments are annoying (R6RS is right) but show that someone cares.

While that's what I grew up with, too, it's probably too isolated anymore.

Find a cheap laptop or desktop, or a pi, install Python3, and make IDLE easy to reach. For graphics, "import turtle" and later "import tkinter".

Grab any learning Python book. It's not that far from how we learned back in the day.

[Chipmunk BASIC](http://www.nicholson.com/rhn/basic/) is a nice console-usable BASIC on most platforms. You can work with it line-numbered, or structured, and has some graphics and sound support in the Mac desktop version.

I started on BASIC on the TRS-80 Model I in 1980, and it was a great introduction.

That said, newbies are probably better off starting Python (use IDLE for a decent REPL & editor), type `from turtle import *; reset()` to get a graphics window, and learning a nice language from the start.

Do you want safe, reliable money at the cost of your conscience? Do you want to be one tiny cog in the machine that tracks and annihilates humanity? Choose Google.

Do you want adventure, high risk of failure, and being able to live with yourself, even if it means struggling sometimes? Choose the startup.

I used elm until late-90s when Y2K looked likely to end it. What I've learned since quitting elm is that mutt was better at processing large mailfiles, and then Apple Mail is easier to automate with AppleScript.

This "Elm" is some sort of JS precompiler, claiming a better program's name? Join the post-ES6 scrapheap with CoffeeScript, TypeScript, and every other joke precompiler. Write JavaScript in JavaScript, and if it's not sufficient, file bugs on ES6/7.

Why would someone use this instead of IDLE, which ships with Python and does the same things?

When using a new version of a compiler, and existing code stops working, it is often a compiler error. When different compilers give different results, it is often a compiler error.

I've hit dozens or hundreds of these, across many languages for decades.

It's not the first thing to check, but once you verify the code is logically correct, that can be the only conclusion.

Compilers aren't excessively complex code, but all code has bugs.

See also: https://mjtsai.com/blog/2017/11/09/enduring-xcode-and-source...

OS X, iOS, and all new APIs consumed by Swift on those platforms are written in Obj-C or C++, never in Swift. So what's "stagnant"?

It's true that few others have adopted Objective-C, GNU & MS occasional efforts aside. Which is why I keep a number of languages in practice.

But fragile, power-hungry, slow-compiling Swift isn't going to beat out stable Java, or easy JS or PHP on servers, and outside iOS/OS X, building desktop software needs UI toolkit support and stability.

Which is my point: Building in Swift is total technical debt.

There's a computer called a Mac, and it's run OS X since 1999-2000, which was NeXTstep back to the 1980s, which is where Objective-C & Cocoa (NS = Next Step) come from.

I'm certainly better than average at geometry & visualizing a grid, but that's a skill most people can learn.

Those who do not learn history are doomed to be the butt of Santayana jokes.

Objective-C code from 30 years ago still compiles and works; many of the NS* APIs still used were stable by then. The tech whims of Kids Today™ don't tell you anything about long-term survival, because they haven't been alive as long as some of those codebases.

In 5 years, everyone doing Swift is either going to be rewriting their app for the 5th time, or switching to something less like quicksand.

Swift devs keep saying it'll get less fragile, then they rewrite "exceptions", or how strings work, or anything else and all your code has to be fixed line-by-line. I do not believe it'll be stable this decade.

Xcode stops supporting old features in XIB, or a class has a deprecated and then removed property, and the deserialization fails. XIB is not XML with a nice semantic DTD, it's an object serialization graph that happens to use XML.

As a Mac and iOS dev since 2005: For long-term survival and maintenance of your software, XIB and autolayout are slow toxins, and Swift is a swift-acting toxin. You won't be able to recompile your Swift code in a year. Or worse, it'll compile but be semantically different.

You won't be able to edit a XIB without fixing AL issues in 1-2 years, and the XIB will be unreadable in 5-10.

The part of Xcode that used to be Interface Builder is still useful for prototyping, but don't ship that!

Write complex UI in code. Autolayout strings in code aren't as bad as the obscure UI, but one can just as easily compute and set frames.

Choose any language except Swift.

Or, good luck with your walking-dead software.

As the former perpetrator of several hand-coded sites and blogs full of text organized by 52-card-pickup principles, going back to '80s BBS's, online services, USENET, and then Gopher and WWW on a University shared network…

Switching to Wordpress (obLink: https://mdhughes.tech/ ) and slowly reposting the stuff I want visible in an organized, searchable format with a consistent style and a nice CMS is the best possible improvement.

My latest change is a "Starred posts" category, so I can surface the longer, more thought-out pieces and still have ephemeral content like semi-daily music links and status updates.

Manton Reece's http://micro.blog/ is putting Twitter-like interaction under a blog framework, hosted on m.b or on your own site.

Discovery of these things is still hard, and Google's ad-searching site unsurprisingly only surfaces ads, but http://duck.go and social media (like HN) can point you at content you want to see. [ed: sp]