blippage · HackerLangs

A huge thank-you to the dev(s)! I love retro projects like this. I use Dillo daily, although it is for internal use. One thing I use it for is to view gemini protocol sites. The plug-in architecture means that you can render any protocol; gopher and gemini amongst others.

It's so lightweight!

blippage

3 mesi fadiscuss

Finance professor Aswath Damodaran, and others, have made many useful insights as to how AI as an investment is likely to pay out.

One technique is, instead of trying to pick individual winners, look at the total addressable market. Then compare the market size with the capital being pumped in. If you look on this basis, Aswath concluded that collectively AI investment is likely to provide unsatisfactory returns.

Here's a recent headline: "Nvidia’s Jensen Huang thinks $1 trillion won’t be enough to meet AI demand—and he’s paying engineers in AI tokens worth half their salary to prove it"

There are two parts to this. 1. A staggering $1t is expected to be invested in AI. Someone worked out that this was more than the entire capital expenditure for companies like Apple. We're talking about its entire existence here. IOW, $1t is a lot of dough. A LOT.

Secondly, this whole notion that AI is such a sure thing that half the salary will be in tokens should ring alarm bells. '“I could totally imagine in the future every single engineer in our company will need an annual token budget,” he said. “They’re going to make a few 100,000 a year as their base pay. I’m going to give them probably half of that on top of it as tokens so that they could be amplified 10 times.”'

I recall from the dotcom fiasco that service companies like accountants and lawyers were providing services to the dotcom companies and being compensated in stock options rather than cold hard cash like you'd normally expect.

Very dangerous.

As another poster pointed out, this really boils down to FOMO by big tech. I'm expecting big trouble down the line. We await to see if I'm early or just plain wrong.

blippage

3 mesi fadiscuss

> Forth is at this point more of a culture than a language.

As the saying goes, once you've seen one Forth, then you've seen one Forth.

I've mucked around with my own Forths in the past, including one that recognises lexical type, so you could build something like a parser in Forth. I didn't take it that far. Forth is normally conceived as being built from the ground up, but if you're you're going to implement it in C or C++ then you can be more imaginative.

I played around with colorforth for 5 minutes on a couple of occasions, but I ran away screaming. What - just what - the hell is going on? I'm sure it all works for Charles Moore, but for mere mortals it might as well be a klingon control panel.

I think Moore effectively gave up on programming a couple of years ago? There was some strange modification in the guts of Windows and he couldn't get his environment to work any longer. He concluded that the game was not work the candle.

blippage

3 mesi fadiscuss

To add to the cool things you can do with Neoleo, I wrote a little TCL extension that loads current processes into the spreadsheet. I added custom bindings so that you could search for processes, go to its parent, and kill processes.

I'm also half-way to adding a little calendar extension, too.

blippage

3 mesi fadiscuss

Yes, I'm partial to a bit of retro. It does back to around 1991, IIRC. I don't think it had a curses interface in those days.

And check this: version 1.2.2 is available on Aminet, for the Amiga. How's that for a blast from the past?

blippage

3 mesi fadiscuss

Oleo is C, circa 50k of C code, Neo(-leo) is around 5k of C++ code. A 10th of the size, but not necessarily any less powerful. Oleo has some memory leaks in places, whereas Neo has no (known) leaks.

Oleo uses lex and yacc, whereas Neo has a hand-parser.

Oleo is in the style of emacs bindings, whereas Neo is more vim-like, but without the modality.

I think the Neo code is better-structured and more readable (but I would say that, wouldn't I? - although it is far from perfect). C++ generally makes code more readable and obvious, without all that pointer arithmetic.

The internals of Oleo are more complicated. It uses byte-code for cells, for example. Neo stores a parse tree for a cell. So you can see that a lot of programming effort is saved right there.

In terms of speed, I suspect that the original Oleo is faster, although it's difficult to benchmark.

Neo is also heading towards being a library that you can compile in with other C++ code. Plus there's an interface to Tcl, which Oleo never had. So you get a lot of extensibility there which Oleo doesn't have.

I also think Neo is more generally accessible. It's got something in the way of a menu (still early stages), which helps. Neo is just generally less fiddly with editing cells, IMO. The mouse works, too.

Oleo does have an interface using Motif. Very early-90s. There's even an interface to GTk, although I don't think that works properly. I decided to abandon all that and just stick to an ncurses interface. After all, if you want a fancy interface, there are proper options these days like LibreCalc, Caliigra and Gnumeric.

blippage

3 mesi fadiscuss

Visidata is a fast popular data tool in python https://www.visidata.org/ if you just want data entry.

If I may be permitted a small plug ...

Oleo is a GNU spreadsheet going back absolutely donkey years. I cloned the repo here: https://github.com/blippy/oleo and made minimalist fixes to get the thing to compile.

I also based my own terminal-based spreadsheet based off of it call neoleo: https://github.com/blippy/neoleo

I wouldn't say that my project is particularly good, but it does have a number of features that I find useful. The next release will include Tcl bindings, so you can customise some of the workings of the app. There's also a module available where you can go to town programmatically.

It opens up a world of possibilities, including stuff like pivot tables.

  package require oleo
  load-oleo mysheet.oleo
  set ws [toMat]
  set subset [subRows $ws [mand [mstreq 2 foo] [mstreq 3 bar]]

It has what I think is a nice little query language, too. In the last line I select the rows from the spreadsheet sheet column 2 is equal to foo and column 3 is equal to bar.

I'm kinda dog-fooding it at the moment to put in place features that I need. It doesn't have the full equivalence of SQL-equivalent though.

blippage

4 mesi fadiscuss

You can have anything you want. You get what you design for.

However, saying you're committed is not the same as being committed.

Furrowing your brow and saying you'll try harder, even when you mean it, doesn't necessarily work, either.

It needs trade-offs, and a willingness for abandon certain things as trade-offs. It requires an honest assessment.

Stop updating the system every 5 minutes, stop with the advertising, stop with the user is the product mentality. Stop changing the interface. Stop with requiring a user account. Stop with the all your data are belong to us. Simplify.

None of this will happen, of course. Corporate imperatives militate against it.

Wanna improve Windows? How about having a two-year release cadence? Developers can get a technology preview, full of cavaet emptor achey breaky changes if they want. This allows them to develop for the next release.

Sync the development tools (more importantly the libraries) like C++ in with the release. Include those libraries. The pay-off is, as if by magic, if a user downloads a program for Windows N, it will work. No extra libraries will be required because they'll already be included in the OS.

blippage

8 mesi fadiscuss

In the words of Adam Ant: it took us 3 years to be famous overnight.

I also heard about Matt Lucas, of Little Britain fame. He was slowly plugging away at it, and was about to give up. At around 30 years old, he teamed up with David Walliams, describing it as the last roll of the die. Their popularity exploded.

Morgan Freeman didn't become famous until he was in his 50's. Someone asked him if he was upset that it took so long. His response was: "No, because it didn't have to happen at all."

blippage

8 mesi fadiscuss

How about trying to run it on ReactOS?

blippage

8 mesi fadiscuss

Don't forget that Aminet is still receiving regular uploads: https://www.aminet.net/

It's amazing that a platform that's been dead since the early 90's is still getting so much love.

blippage

8 mesi fadiscuss

There's also Fuzix, which is Unix-like. https://fuzix.org/

Supports Arm M0 (Raspberry Pi Pico), ESP32 and a variety of others, including Z80.

blippage

9 mesi fadiscuss

For anyone interested there's tinybasic, which will run on something as small as an Arduino.

https://github.com/slviajero/tinybasic

blippage

3 anni fadiscuss

#embed is what I really want. And separators.

> Standard C advances slowly

They're not joking, either. C is conservative to a fault, I think.

blippage

3 anni fadiscuss

The big tip-off that all is not as it seems is that he calls himself "Uncle Bob" Martin.

Functions should do only one thing. Sure, but what does that actually /mean/? If a function calls two other functions, then surely, by definition, it's doing two things? So how much a function is doing is a question of how far you stand back when looking at it.

Also, if you follow a rule of functions having only 2-4 lines, then you're going to have a lot of functions, and tracing through code paths is going to be like peeling back layers of an onion. So that advice is just wrong.

It's not even clear that long functions are a problem. Back in the early 80's my A level computing science teacher, who had worked in industry, said that there was no real evidence to suggest that long functions are less readable.

There was a joke going around some time ago about an interviewee who was asked how big a function would be. He said "I like to be able to keep it within my head." When asked to elaborate, he said "I put my head against the screen. If the function is longer than that, then it's too long." Although facetious, I think that's actually a good idea. A function should be at most a screenful, so you can see it complete on the screen.

Recently, I wanted to customise my own gopher client. I first messed around with one written in Go, but it was too complicated to adapt for what I wanted. I switched to a C alternative, which was still a bit too complicated. I decided that I'd basically re-write the whole thing in C++, using whatever bits of functionality from the C part that I thought useful.

If there is a magic formula to writing good code, then I'd say that the less code you have the better, and try to keep code reasonably decoupled. The problem with writing applications is that there's a tendency to be promiscuous in how you use objects. So, in essence, every part of the program relies on every other part of the program. There's no separability of design. It is better to take a "library" approach to things, where each "module" doesn't know how it is going to be used. You then have co-ordinating functions which stitch this functionality together. The code you end up with should be much easier to adapt.

It's also useful not to be overambitious with your project. Someone once said that the genius of Ritchie and Thompson was being able to obtain 90% of the functionality using 10% of the code. If you think parsimoniously in that way, they'll be a lot less code to wade through when you want to modify things.

comments