Over the last three years I have been doing a focussed investigation of a lot of different programming languages and styles (about 38 last count). I was reflecting over the weekend which one I really liked best. Not really for features or functionality or toolset just which one felt 'right'. Julia came out on top as the one language I wanted to play with more and I wish could give a reasoned well justified argument for it but it's really just a feeling. The right mix of intelligent design, power, absence of evangelical idiocy, and a pleasing interface. So nice to get that feeling validated from the random workings of the world and see this release message this morning. Thanks Julia team.
> Over the last three years I have been doing a focussed investigation of a lot of different programming languages and styles
I don't know what your invesitgation covers, but a long time ago (2009) someone [0] did an interesting visual comparison of languages. sadly now it seems it's only available at archive.org [1], but I've often gone back to it, partly because it's such an elegant way of looking at some aspects of different languages.
I liked Julia the first time I tried it years ago. I had some Matlab experience, so it seemed a similar, yet great improvement (no cost! more modern, but lacking some key libs or toolkits). I started programming Commodore BASIC in 1977 on my PET 2001. Then 6502 Assembler/machine language, C, Turbo Pascal, and many more. I have recently gone back to assembler because of AI. I don't miss hand coding assembler or creating macros that don't exist in FASM, but AI allows me to prompt for a terse program, using tried and true asm methods, which I can then audit. Julia has great math and scientific libraries, so my asm stuff isn't in competition with my asm efforts, but I am really enjoying the asm/AI thing for now. Granted this is for my own small projects. Coding is not my main job. I use coding in my other jobs to help me with certain tasks like scheduling, simulations, engineering, and project management. I was playing with the Julia version of cadCAD that was on Python, however, Julia has a lot of other libs that are way better to do dynamic or complexity studies than cadCAD.
As you mentioned 38 languages, chances are high that these languages are not all coming from a scientific background, where 1 index based adressing of items is the norm. What is your take in respect to Julia, which is also one offset based?
One-index based addressing of items was the norm in most of the mathematics or physics books written before WWII, but even then there were exceptions, e.g. for the components of a quadri-vector or a quadri-tensor, i.e. for spatio-temporal vectors and tensors, it was already common to use the indices 0, 1, 2 and 3 for the temporal component and for the 3 spatial components, instead of the indices 1, 2, 3 and 4.
However, this tradition is worth nothing, because before automatic computers the use of decimal numbers instead of binary numbers was also the norm, like also the use of big-endian numbers instead of little-endian numbers. Having to actually implement the computational operations in hardware has revealed that many such traditions were sub-optimal.
Despite the fact that among my programming interests the scientific-technical computational problems have always been on the top and I have started programming with the Fortran language, I have always recognized that using 1-index based array addressing is inferior and any programming language that uses this convention makes a mistake, because this increases the chances of programmer off-by-one errors, by requiring more complex index expressions in many cases.
If anything, my opinion is that programming languages should not support any of such obsolete "norms", but they should go further in replacing them.
For instance, I believe that for integer constants and printed numbers it is still OK to use decimal numbers, because this simplifies mental computations for most humans, who have memorized the multiplication table of decimal numbers and because the conversions between decimal and binary integer numbers are exact, so it does not matter which base is used to display them to humans.
On the other hand, I believe that for floating-point constants and printed numbers it is a mistake to use decimal numbers, instead of using hexadecimal numbers for the significand and decimal numbers only for the exponent (like when printed by printf with the %A or %a conversion specifiers). The reason is that the conversion between floating-point decimal and binary numbers is slow and inexact, introducing rounding errors, without providing any advantage for a human who reads the program text or a table with results.
Comparing hexadecimal floating-point numbers is actually faster and easier for a human reader, than when working with decimal numbers, because the numbers are shorter. Except for comparison, a human will not do any other exact mental computations when reading a set of floating-point values. (At most, when looking at a column of numbers displayed as fixed-point values, a human might add one or a few of the digits, to check that their sum matches the corresponding digits in a displayed total value, but unlike multiplication, addition is almost as simple for hexadecimal numbers as it is for decimal numbers.)
Approximate mental computations are also easier to do with binary floating-point numbers than with decimal floating-point numbers, if you understand how to do them (which is by using logarithms in any mental computations; this is true for both binary and decimal floating-point numbers, because approximate conversions between numbers and their logarithms are very easy to do mentally, as any engineer working with decibels knows). Doing just the simple operations with exponents provides already a better accuracy than for decimal numbers, because an octave is smaller than a decade. For additional accuracy, it is usually enough in mental computations to approximate the floating-point values to 3 points per octave, in which case the approximation error is about the same as when doing approximate mental computations using decibels.
In decades of programming, I have never encountered any case when I would have wanted for my program to contain decimal floating-point constants, or for any result to be printed as a decimal floating-point value, but I have encountered the opposite case, when a programming language annoyed me because it forced the use of decimal floating-point constants, which introduced undesirable rounding errors, so I had to use equivalent integer constants and use something like memcpy to convert them into the desired floating-point numbers.
Agreed. AI doesn’t level the playing field but turns it more in a winner takes all situation. AI is currently best in Python programming from what I hear and this is because it has seen the most Python code.
No matter how much code it has “seen” during training, it still makes mistakes during inference. Therefore AI is most well-suited to write in languages with feedback loops that catch mistakes earlier.
Moreover, no matter how good it is at writing Python, Python is not a language you want to use everywhere. “The right tool for the job” still applies in the age of ai.
Even before AI the trend was moving toward increasingly static languages (JS->TS and even a lot more typed Python). Once you accept the static typing benefits, you start to wonder if you could leverage the constraints to drive performance improvements.
Static typing makes it easier to do RL targeting the sorts of things that static types encode, but it doesn't help at all with things that aren't really type constrained, like for instance writing accurate numerical programs.
Yes. Supports .md but when you try to save back to .txt it does something to line endings that you cannot see in notepad but if you grep your .txt files from wsl like, I do all the time, you get page long strings instead of matching lines. It's weird and I haven't dug into the cause as it was easier to save as a new note but pretty sukky for an IT company to miss something like that.
But this would result in showing double newlines, when you view a CRLF file with an LF viewer, that also interprets CR. This does sound more like the file would have only CRs, which is what classic Mac did pre-Darwin. But that doesn't make any sense.
Maybe Notepad is actually saving LF, but marks the file as CRLF and some WSL translation layer then triggers and removes LF, because they are not CRLF?
Line endings between windows and Mac/Linux have been a problem basically forever. Windows uses carriage return and the others use newline or something like that.
Now this is the juicy tidbits I read HN for! A proper comment about doing something technical with something that's been invested in personally in an interesting manner. With just enough detail to tantalise. This seems like the best use of GenAI so far. Not writing my code for me or helping me grock something I should just be reading the source for or pumping up a stupid start up funding grab. I've been working through building an LLM from scratch and this is one time it actually appears useful because for the life of me I just can't seem to find much value in it so far. I must have more to learn so thanks for the pointer.
Good article and interesting technical description. Stays on the side of "proud developer keen to share details others would find interesting" and away from the "I made a game and here is my blog to advertise it". I do like hearing about Playdate development and wish I had one. There is lots of other Doom-like games out there with decent descriptions of the ray casting algorithm but the additional tweaks you made for the platform are fascinating.
reply