Hacker News Reader

> It feels like it's becoming a simpler language, as in many cases, it takes much less effort to tell the compiler what I want to say.

I do not think this shows that Java is a simpler language, if anything it shows that it has more features (ie. being more complex as a language) that make it easier to match what you want to do.

Java might be simpler (easier) to use, but that doesn't make it simpler as a language itself.

For a more extreme example take C vs C++ - C is certainly simpler as a language than C++ and nobody would ever claim that C++ has any relation to simplicity as a language whatsoever, but a lot of things are much simpler to do in C++ than they are in C because of all the additional features C++ provides.

So its semantics over the meaning of simple - some mean simple as in not meany features, the other means simple to get things done with. Many people call C a hard language because it's quite hard to get stuff done with it, while others call it simple because the feature set is small and writing compilers for it is relatively easy.

IMHO the reason why it's "hard" to get stuff done in C (which I don't necessarily agree with), is mainly the bare bones stdlib, less the language. Eg C programming is much more library-driven than language driven. It sucks if the used libraries suck (such as most of the C stdlib), but it is great when using libraries with a modern API design (eg the opposite of POSIX).

From the perspective of most high level programming - say web development, C has no advantages whatsoever.

Hmm, every piece of web infrastructure I just thought of (every browser, nginx, FreeBSD, your HL language runtime, nghttp2, curl, SSL) is written in C.

Sure, you may not be touching those during your web development, but that’s because you don’t know how to have fun and outsourced it all.

web infrastructure is not the same as web development...infrastructure is what allows developers and users to build and use the apps. C does make sense for these things. Stuff like Curl I think is written in C more due to historical reasons (Unix is written in C so all of its apps are in C), I don't see any major con if it was written in Python (which is a big high level wrapper over C in the end...) - it would be a tad slower and a bit more memory yeah, but in todays world I don't know how much of a difference it makes.

> I don't see any major con if it was written in Python

> it would be a tad slower

a tad? I'll use C++ as an example, but the last time I profiled a hash map in C++ vs C#, the C++ lookup took 1 nanosecond[0] and the C# version took 1ms (1000x slower) (I don't have these metrics anymore but I believe it was one ms or slower, and Google seems to confirm that).

Now, if the difference between C++, a machine compiled language, and C#, a runtime compiled language, is 1000x for a very common operation, how much slower will an interpreted language that is running at an even higher level be??

The reason 90% of our apps are such slow trash these days is because programmers think that there is no difference in a couple milliseconds when it is a huge difference if that couple milliseconds is being run thousands of times through hundreds of thousands of lines of code! Take a look at how fast the Jai compiler is compared to a modern C++ compiler. Or even a C compiler vs a C++ compiler. It's night and day because of how much cruft slowly gets added on.

So I find your claim that most of the Unix utilities are only written in C because that was mainstream in the day highly dubious. If anything, they would be written in something like Rust today, but definitely not JS or Python.

Edit: I would also like to point out how much of a pain it would be to write low level network code, like what's necessary in curl, in a language like Python. When you're writing low level net code you want as little interference between the bytes and the programming language. Because if your bytes have some hidden padding, or the endianess is swapped, or a data structure is aligned a byte off, it means the difference between between correct transfer over the net, and sending garbage over the net. Python is not conducive at all to understanding how an object will be transformed into q series of bytes, whereas C is almost a direct translation from a struct to a series of bytes.

[0]: https://gist.github.com/ambrosiogabe/66a6e2fdc77e6a600e570f4...

I might be wrong about curl - I use it just as a tool to make http calls but it might be more complicated than that - but why can't you build curl with python's http libraries? I guess there are use cases where you have to manipulate responses on the byte level?

> the C++ lookup took 1 nanosecond[0] and the C# version took 1ms (1000x slower)

The ratio between 1 ns and 1 ms is a million.

The link talks about nano- vs micro-seconds, so probably just a typo.

I just re-ran the benchmarks and I was mis-remembering those statistics quite a bit. It looks like C# takes 124.5 nanoseconds on average for a hash set lookup. This was benchmarked using BenchmarkDotNet :)

C# definitely does not take 1ms to look up something in a hash map. Perhaps 1us (microsecond) in a horrible example if the virtual hash code has a slow algorithm and doesn't cache the result.

Regardless, the benefit of not using C++ is and always has been: Not having to use C++.

Yep you are correct, I was mis-remembering quite a bit. I just re-ran the tests using BenchmarkDotNet and C# takes 124 nanoseconds on average, which is still 100x slower and a considerable difference, but not orders of magnitude difference :)

C# benchmarks on my machine. FastFindRecipe just does a hash set lookup, it looks like this:

  private static readonly HashSet<CraftingRecipe> FastList = new HashSet<CraftingRecipe>(new CraftingComparer());
  public static CraftingRecipe? FastFind(CraftingRecipe r) => FastList.TryGetValue(r, out var res) ? res : null;

  |         Method |     Mean |   Error |  StdDev |      Min |      Max |
  |--------------- |---------:|--------:|--------:|---------:|---------:|
  |     FindRecipe | 315.2 ns | 1.17 ns | 1.09 ns | 313.6 ns | 317.4 ns |
  | FastFindRecipe | 124.5 ns | 0.23 ns | 0.21 ns | 124.1 ns | 124.9 ns |

> , which is still 100x slower and a considerable difference, but not orders of magnitude difference :)

Two orders of magnitude.

I see this sort of argument for low level, system languages all the time. What you're not considering is that runtime isn't the constraint that we're hitting anymore, it's developer time. There's no doubt that a good python dev is much more productive than a good c dev, both in terms of raw output, and in terms of writing code with fewer bugs. 'Software is eating the world' is overused, but broadly true, and the reason we devs are so well paid is because the demand so vastly outstrips the supply of productive devs.

My argument here is about developer time though. Python development for low level systems programs would be astronomically slower than using a language like C, C++ or Rust which are built for these things. Use the proper tool for the proper job.

If you have to have multiple structures that need to be precisely laid out in binary, python is the wrong tool for the job. Delivering content using Tcp or Udp packets requires very explicit binary definitions of the data your sending. Sure you can use a wrapper on top of a library that deals with the low level stuff, and that's what Python is all about.

Use the proper tools for the proper jobs. If you're using C to write one off scripts or simple data manipulation like analyzing csv contents or something, then you should probably use a higher level language instead. If though, like curl, you have to be very explicit about the binary description of objects to accurately send and receive those objects between a network, then use a low level language.

> runtime isn't the constraint that we're hitting anymore

If you're sending data over the network you're absolutely hitting this constraint. Reading some data from RAM is on the order of like nanoseconds, sending data over the network is on the order of hundreds of milliseconds depending on the size and location you're sending that data. When it comes to sending data over the network, literally every byte does matter.

My point was more broad. We're not short on compute power in most cases, we're short on dev time. If you're talking low level microcontroller stuff, or bit banging, sure, do it in C if you like. In general though, I'd rather devs using a higher level language that gives them tools to deal with things like memory management and concurrency. The slowest code is the code that was never written, not the code that takes an extra 100ms because it was done in python instead of C.

> I see this sort of argument for low level, system languages all the time.

It seems like you were advocating using a higher level language for low level, systems programs. If that's the case I disagree. My original argument was about Unix utilities. Unix utilities contain everything from "list the files in a directory" to "compile this C program". The original poster was talking about how Curl would probably be written in Python if it was written today. This is just incorrect. From the author of curl[0]:

>> If I would start the project today, would I’ve picked another language? Maybe. Maybe not. If memory safety and related issues was the primary concern I had, then sure. But as I’ve mentioned above there are several others concerns too so it would really depend on my priorities.

> If you're talking low level microcontroller stuff, or bit banging, sure, do it in C if you like.

This is the argument I'm making. Unix utilities are usually dealing with low level bit banging stuff. Unix utilities are also meant to be extremely portable. C is the glue that holds all programming languages together, whether we like that or not. So programming a library in C automatically ensures that the library can be used in practically any higher level language.

[0]: https://daniel.haxx.se/blog/2017/03/27/curl-is-c/

These 'frontend web projects' are all written in C, or a mix of C and C++ though (and I'd wager that doing the same thing in JS would have been more difficult, at least the emulator stuff which is mostly bit twiddling code):

https://floooh.github.io/tiny8bit/

https://floooh.github.io/sokol-html5/

https://floooh.github.io/visual6502remix/

The common pattern is though that both the C and C++ stdlib are mostly useless for this type of project, you need cross-platform libraries where 'cross-platform' also includes peculiarities of the web browser runtime, specific language features are (mostly) irrelevant in this case - except maybe for the bit twiddling thing in the emulators where C is clearly superior to JS (plus you get lean native versions "for free" without requiring a heavy Electron runtime).

> semantics over the meaning of simple

Thankfully there are two different words with very separate meanings that people nonetheless tend to conflate [1]. "Simple" means "not many features", and "easy" means "good to get things done with".

[1] Maybe because we have lots of people speaking English as a second language? In my mother tongue, German, there is no distinction in vocabulary between "simple" and "easy". Both translate as "einfach".

It's been hinted at in this subthread a few times, but Rich Hickey's keynote https://www.infoq.com/presentations/Simple-Made-Easy/ about simple and easy is worth a listen/watch.

> "Simple" means "not many features", and "easy" means "good to get things done with".

I'm not sure about this. What utility is a language with only simple constructs that is hard to use.

Not quite a counterpoint, but a thought in that direction is:

There can be features that make it easy to implement something which some find hard to understand.

I suppose I question the value of simplicity for it's own sake in a language and would rather defer to how simple and understandable the resulting code is.

I frequently consider the added complexity cost of a more complex compiler inherent complexity because I find the simplicity of use dwarfs compiler simplicity or simplicity "just cuz".

Not much of a difference even among native speakers. If you pose a problem to someone, and they think they have the answer immediately, they're about as likely to say 'that's easy!' as they are to say 'simple!'

I’m not so sure, when I look up the definition of simple it starts with “Easily”. In my native english speaker mind simplicity is a type of easiness.

Though if we want to make the clear distinction, like in the Clojure talk below, for the programming domain that’s fine.

"einfach" sounds a bit naughty...

For me, simple is in the amount of concepts.

For example, I consider most multi paradigm languages complex because in them functions, variables, objects, control flow, etc. are fundamentally different concepts.

But something like LISP, smalltalk or Haskell are simple in my eyes, due to almost everything being the same concept on a fundamental level and the other stuff being built on top of that concept.

The problem is when simple vs complex is used as a value judgement, implying that simpler is better. It's not that simple.

Conway's game of life has an incredibly simple definition, and is Turing Complete. The Brainfuck language has a minimal number of language concepts and barely any syntax. And yet, programming in these languages is very hard.

Humans need a certain level of language complexity to be able to express themselves. When you simplify things it's not always clear if you're removing superfluous complexity, or removing tools needed to deal with inherent complexity of the problems you need to tackle.

I don't think there's even any single objectively appropriate level of complexity, because it depends on the complexity of the problem the language tackles. By analogy to human languages: scientific language has its own jargon (sometimes overused!), but it needs an extended vocabulary to precisely describe the things and problems it works with. Without the added complexity it'd be unproductive due to being verbose and sometimes ambiguous, like the amusing example of Up Goer Five: https://xkcd.com/1133

As I am not good with words, I am just gonna take this: https://news.ycombinator.com/item?id=31492953

Specifically what I wanted to express, is that, for me, the turtles all the way down is what I understand as simplicity.

And yeah, simplicity alone can't be used as a value judgement.

Lua 5.1 is the most amazing language design I've ever come across; you can do almost anything with this language and it's as minimal as it gets. It is true that dynamic typing sets limits in terms of project size.

Have you ever built anything complex in it though? One of the pains of professional lua development is how much lay users admire its design. And it is true that its design is elegant and emerges from interesting and admirable constraints.

In practice though it doesn't give you any of the tools you need to do anything except make tools to do those things. Which appeals to yak-shavers like us for sure. But if you need to sit down with it for months at a time and just get work out the door it fucking sucks.

Also 5.1's GC is goddamn tragic. In practice you're usually at the mercy of whatever was implemented by the embedding runtime, but if you're ever left alone with just the raw 5.1 GC you'll wish you weren't. Later versions improved that dramatically.

Can you elaborate on why the 5.1 GC is so bad?

Honestly I'm not an expert on that part of the lua internals so I can't confidently say why. I don't think it's a fundamental problem since later versions use the same approach afaik, so I assume it's just implementation nuance. 5.0 used, IIRC, mark-and-sweep which is not great either but it's predictable: it's easy to develop intuition for how much you're allocating and what the collection cost will feel like.

The main practical issues I've run into with 5.1:

  - per-object overhead in time and space both increased significantly, making many small allocations much more expensive than fewer big ones. further pushing you into the "mutate a few huge global tables" pattern that is already a problem in lua conventions.

  - some of lua's more lauded and genuinely powerful features, esp metatables, don't work smoothly or predictably with the GC. it leads to people trying to manually tune it with __gc metamethods, which is hard to do correctly and causes memory leaks if done incorrectly.

  - weak tables idk,. esp with strings for some reason. similar to the __gc, there is a solution there but in practice it's very hard to be sure you've got it right and it's worse to get it wrong than to not try.

I'm sure a PL expert can explain and justify all this but I am just a normal person who codes for money. Lua is admired for being simple and accessible, but especially in the older versions you get into the low level weeds real fast over this stuff. Kind of a good example of minimal implementation exposing you directly to irrelevant complexity, really.

This is nonsense; where do you have that from?

I'm using it since 20 years (e.g. for http://cara.nmr.ch/doku.php, or e.g. this one https://github.com/rochus-keller/Smalltalk), also used it as backend for programming languages and developed tools on it (e.g. https://github.com/rochus-keller/LjTools/). Is this complex enough? Never had an issue with the GC.

> you're usually at the mercy of whatever was implemented by the embedding runtime

Are we talking about the same Lua? The engines I know (PUC Rio and LuaJIT) are not at the mercy of embedding runtimes, but haver their own, sufficiently good memory management.

We might not be talking about the same lua! Like I kind of hinted, I think it's likely very good for expert users to build tools on.

I'm not an expert user of anything though, or building tools. My professional experience of it has been using ancient versions that are embedded into C or C++ systems to build simple guis and automation within those systems. I don't think it's well suited to this, but this is a common (I believe even it's original?) use case!

I've never used luajit, or any version where I had full control over the runtime at all. I understand people love this language and I'm not saying they're wrong to. But for the things I've needed to use it for it has not been enjoyable at all, particularly 5.1 which is the one I have the most experience with by far.

I've used a lot of different embedded scripting languages with C and C++ and Lua is by far the most efficient and easiest to integrate one. Especially the 5.1 version is excellent and I still use it today. In what notable project have you used Lua?

> I'm not an expert user of anything though

But apparently confident enough to make negative comments about the technology.

Yeah pretty much, sorry. I do this for money and generally more or less enjoy it as far as that goes. But I've always had a miserable time working in lua, more than any other language I've touched professionally.

I might be wrong about the technical reasons why, and I'm genuinely sorry if I've unfairly maligned your baby here. But it has always been unpleasant for me and I think I'm entitled to my confidence about my own experiences in it.

It's not my "baby", just one of many programming languages I'm using or design myself; but is't a great example for how good you can get with a minimal language design. Personally I prefer strictly/statically typed languages.

> Have you ever built anything complex in it though?

I have, yes, it's great. No complaints, would choose LuaJIT again.

I do regret that the quad-color collector will likely never be implemented, I'd content myself with a back-port of the new generational collector, but the allocation sinking in LuaJIT has kept me out of trouble for the most part since it can put 'tables' on the stack if it can prove they don't escape.

> though the lambda calculus, SKI combinator calculus, or and MOV-only assembly are minimal in very real ways, the cognitive burden of expressing yourself in these languages is very, very high!

But much less high with the lambda calculus than with the other two; Haskell is not far from being a layer of syntactic sugar on top of the lambda calculus.

For an example of a non-trivial lambda calculus program, see this self-interpreter [1] for binary lambda calculus [2].

[1] https://github.com/tromp/AIT/blob/master/uni.lam

[2] https://www.ioccc.org/2012/tromp/hint.html

True! I think pattern matching and the high-powered static type system really pull a lot of weight here, though. Haskell's types are a whole other dimension of domain modeling. You can encode algebraic data types as pure lambdas, but it's much less pleasant IMHO. (Laziness also bakes some common streaming patterns into the language core, which I find really nice, but it also makes it harder to totally understand what's going on sometimes, so it's a bit more of a toss-up.)

Point being, nobody wants to model their data structures as pure lambdas; even primitive integers are an addition on top of the lambda calculus.

> For an example of a non-trivial program

I don't think I'm taking the point you wanted me to from this program. It's under 30 lines, yet I'd need to pore over this for twice as many minutes to comprehend what it's doing. I can see the lambda abstractions and applications clear as day, but what they're doing I couldn't say. (The comments clearly say it's a universal binary LC interpreter, but we don't usually judge languages by their comments.)

EDIT: Right, okay, it's a submission to the the International Obfuscated C Code Contest. If it's obfuscated, then indeed, I'm not meant to comprehend it easily. Not sure that sells the lambda calculus.

Spoiler alert, but if you want a tutorial on understanding Tromp's calculus, then here's the readable version of his IOCCC entry with cryptograms and everything deciphered. https://justine.lol/lambda/

> pure lambdas

Also, in lambda calcalus there is no recursion built-in. You have to build it yourself with the Y combinator.

Right; you just add definitions you need like

let Y = \f. (\x. x x) (\x. f (x x)) in program-using-Y

which is the slightly more legible version of

(\Y. program-using-Y) (\f. (\x. x x) (\x. f (x x))

> You can encode algebraic data types as pure lambdas, but it's much less pleasant IMHO

Not that much less, since you can manually translate back your Haskell code to lambda calculus. E.g. your

    List a = Nil | Cons a (List a)

rewrites to

    let
      Nil = \n\c. n
      Cons = \x\y. \n\c. c x y
    in ...

Of course the type system is what helps you write correct Haskell code in the first place, so the untyped lambda calculus will be painful for debugging wrongly typed code.

> I never got the sense that [Lua] could scale much beyond one-person projects.

I had a misfortune to deal with more than 200K lines of Lua code back in time [1]. It seems that my experience doesn't necessarily match those of other big Lua users though; it does seem to work when everyone is willing to invest in self-contained environments. In the other words successful Lua users doesn't exactly use Lua, they use their own programming systems based on Lua. (I should note that such systems are not guaranteed to be successful, as evident from my case.)

[1] https://news.ycombinator.com/item?id=18351788

> I never got the sense that it could scale much beyond one-person projects

It can be done, but it requires a lot of discipline.

You might enjoy Teal, a sort of "Typescript for Lua" https://github.com/teal-language/tl

> Nonetheless, it's not a great fit for most domains; for instance, I never got the sense that it could scale much beyond one-person projects.

I don't think it's really missing features compared to Python or Javascript that would help with this. Tooling could improve a lot though :)

> I never got the sense that it could scale much beyond one-person projects.

Adobe Lightroom?

I'll wear that; I'd heard of Lightroom in the context of Lua, but I've never used it and don't know what it's for. Looks like its plugin architecture is a major selling point? Seems like a great fit for Lua.

The UI widget toolkit and the low-level image processing code are in C++ but the people involved have said that the remaining half of the application is written in Lua. Nothing to do with plugins, really.

Cool! I'd be curious how large the codebase is, but it's cool to hear that something like Lightroom exists at all.

Given that it's made by the people who created a printable document format that supports embedded videos, I'm going to assume that it's an alarming large codebase.

The name PDF stands for portable document format (the name itself isn't that relevant, but also the intention).