[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.
Great response, I really like chicken when working on Mac or Linux, but it's windows (where I do most of my development) that it struggles.
Some eggs just don't install and the error messages are really bad at that point. Trying to install awful to develop a web api I had to give up, couldn't find a way of getting it installed on windows (no problem on OSX or Ubuntu 18.04)
Installed Portacle and (ql:quickload "hunchentoot") and was up and running in a few minutes.
A lot of lisp-languages could do with an equivalent to Portacle, an opinionated dev environment that you can install and just start coding, an area that Racket is excellent in.
Cygwin is the best option because you can easily access all of the installed binaries for use with GUI emacs running in windows.
But I don't consider that to be a real native option, it is some kind of weird halfway house that sort of installs linux binaries but they are also kind of windows ones polluting your windows path.
Currently SBCL 'just works' on native windows, which puts it ahead for me if you are happy with both Scheme and CL.
I really wanted to love Chicken but I remember finding a number of eggs I wanted to use that were broken for OSX. If I were a better programmer I guess maybe I could have figured it out.
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.
Although, if Racket is for educational uses only, if you see their main website you will notice that it is actively preparing itself to become the next Python.
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.
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.
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.
> Without the experience of making and supporting such tools, you'll never acquire wisdom, or many useful skills.
There's nothing special about those specific tools. Instead, you'll acquire the wisdom and skills from the experience of making and supporting different tools. Ideally tools that don't already exist thousands of times over.
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.
> Go ahead and invent some totally unique tool nobody's ever seen before.
I think people invent totally unique tools[1] all the time but, crucially, they'll be commercially sensitive or rarely of interest or use to anyone else.
[1] Of course, it depends how you define this. Decades ago I wrote something to blank out (not strip) comments in C++ source for someone. Is that a 'totally unique tool'?
> And to a certain extent, I don't consider people incapable/unwilling to do this "programmers". Merely typists.
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.
You can't possibly mean his "Code: The Hidden Language of Computer Hardware and Software" or "The Annotated Turing: A Guided Tour through Alan Turing's Historic
Paper on Computability and the Turing Machine"? These books are great.
Those books were both brilliant. I don't recall his tech books being "bad", at least in terms of being somehow worse the the other Windows programming books that several large publishing houses cranked in volume.
I first came across Petzold this weekend while watching a talk by Robert "Uncle Bob" Martin on the future of programming. Martin was discussing Turing's paper "On Computable Numbers" and recommended reading it and Petzold's "Annotated Turing". I currently have Petzold's book on my "to-buy" list so am glad to see it spoken of highly.
> Based on a totally unscientific survey (those programming languages that occupy at least 3 feet of shelf space in the McGraw-Hill Bookstore in Manhattan)
Use a bad metric, get bad results.
Who else remembers this era of giant, unhelpful, rapidly-obsoleted books in the computer section of bookstores? Who remembers bookstores? OK, OK, I've been into Waterstones recently, but it never occurred to me to look at computing related books. What use would they be?
1996 was the beginning of the O'Reilly heyday. If you got a book with a white cover with a coloured bar and animal woodcut on it, there was a good chance of it being helpful. Otherwise it was a lottery - there was a cottage industry of people turning out bad books about software filled with screenshots that mostly replicated the online help.
Next level: fill whole pages with output from random Linux commands with 4 verbosity flags set: https://imgur.com/a/rnVE9u4
Spent 45 EUR on this Linux Network Administration handbook by Addison-Wesley Germany as a teenager. Still hurts whenever I think about it.
(Yes, the author also did the screenshot thing: "Look, this is how you configure it using SuSE YaST, and this is how you do it using the Red Hat GUI. Let me show you every single step of the wizard GUI, just to be sure. And this is basically the whole default config file for this daemon, but with "# Created by Bad Tech Writer" prepended. There you go!")
I can only speak for myself, but I was and am a Microsoft hater. I bought and play-tested VB, decided it was garbage and never used it again. Delphi allowed me to "do" Windows GUIs elegantly, without all that Petzold garbage and the many limitations of VB. I also loved Delphi 1 for its world-class truly useful help files.
I enjoyed Delphi's performance and recommended it to a customer for that reason, but my own primary motivation was to avoid the terminally cumbersome Windows API.
I still maintain a legacy Delphi 7 application and I completely agree with you about the help files. It's so complete that 9 out of 10 times I don't need to search the Internet for the information I need. Every time I press F1 on another application and my browser open a poorly written documentation I miss those Delphi help files.
Regarding Borland, as historical note, Microsoft C/C++ 7.0 for MS-DOS was the very last MS-DOS compiler to add support for C++.
Borland was already selling version 3 of their compiler by then.
On Windows side, Object Windows Library and Visual Component Library were much more productive, ahead of time Qt, than MFC ever was.
But then Borland's missteps meant that MFC was the only framework left, and only a couple of enterprises still get to enjoy C++ Builder's RAD productivity.
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.
Discord uses minimum 140mb of RAM when idle on my machine. VS Code is currently idling at 330mb for me (2 files open), and it's a fork of Atom that allegedly performs better.
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.
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.
[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.