-
I don’t think there’s anyone or anything stopping people from using “heavyweight” setups. This post reeks of “stop liking what I don’t like”.
-
I’m certain IRC will outlive all the competing proprietary text cha protocols that are much more popular right now.
-
By the way, this is a part of what Ubuntu motd contains now:
-
Check out 6 great IDEs now available on Ubuntu. There may even be something worthwhile there for those crazy EMACS fans ;)
-
-
Wouldn’t want all those crazy Stallmanites hanging around calling them on advertising non-free software, which you can get from their new package manager that caters to for-profit companies.
-
-
-
Writing a
robotfindschickenclone in Scheme for kicks. It’s fun but feels sorta sinful to write in a nearly purely imperative way in a language like this. I guess there’s no way around withncurses.-
Scheme FRP library?
-
-
-
I am interested in personal opinions about CHICKEN vs Racket. I want to get into one of them but I am not sure which one. I am looking at them from the point of view.of someone who likes developing web and apps. Can anyone share some of their experiences with me?
-
Caveat: I’m a CHICKEN user.
Racket is a kitchen-sink/batteries-included kind of Scheme that compiles to bytecode that runs in a virtual machine. It’s got the largest Scheme community and ecosystem by far. It seems to excel in GUI in particular. It also has its own varieties like Typed Racket and Lazy Racket, which are quite neat. (You could argue that Racket is a separate dialect of Scheme at this point, as it doesn’t exactly follow the RnRS.)
CHICKEN is a much more minimal Scheme dialect that compiles to C. It’s fast and portable, and the compiled applications are very easy to deploy elsewhere, given you bundle libchicken.so with the executable (or statically link it). It has a very clean C FFI. It implements most of R5RS with growing R7RS support.
Honestly, if you like developing web apps, I’d personally recommend Racket since it has a sizable and mature codebase for web dev, mostly using a sublanguage called Insta.
-
On top of other comment, Racket has advantage of How to Design Programs written for it.
-
-
I guess it’s a bit of a moot point, since it’s an Electron app, but I’d like to bring up the fact that Win95 could comfortably run w/ 16 MB core.
The type of apps I used to run without delays on a Win98 Pentium 200+MHz w/ 64MB of RAM continues to be an illustration of how bloated today’s apps are.
I don’t mean to sound like a grumpy curmudgeon repeating the same old gloomy refrain, but I believe that some day Wirth’s law will win over Moore’s law.
I’d have previously say it was in embedded at least. Then, the recent surveys on that show they’re cramming all kinds of complexity into devices that ought to be simple. A lot can’t be simple given even basic requirements like WiFi on top of something that otherwise might use 8-bitter with simple, control software. Wirth’s philosophy was never grounded in user psychology or market economics. Seems stuff has to be overcomplicated at least a little bit even in sectors benefiting from simplicity. That’s even happened for “high-assurance” systems to a degree where market demand forced more politics into evaluations increasing complexity.
I’m not saying Wirth’s philosophy is dead. I’m saying it was always partly wrong with even more potential proponents working against it. I always respected it but thought it overly simplistic. The compiler heuristic was especially bad once hardware got faster. I’m still about leaner baselines. I just think a bit more complexity in language and stack is good if it makes every app on top have desirable qualities. Wirth was always willing to complicate everything on top to make compiler/runtime/OS simpler. That’s backwards to me after watching how people actually use those things.