Hacker News Reader

>Quick, name a language where I can do something simple like mention "Whenever this function is called, make sure there is enough free memory (at least ---- MB) before actually calling it; if there isn't, first swap out any objects from memory to disk, starting with the ones that had been used the longest time ago, and after the function has finished running, swap those back into memory."

The first fallacy is thinking that this is "simple" merely because it is "well specified".

The second fallacy is thinking that this should be the task of a language.

"The second fallacy is thinking that this should be the task of a language."

Yes. This should be the job of the OS, not the programming language.

In my opinion a language should do whatever I want. And in the future languages will.

By the time languages have the DWIM feature, AI already took the whole job.

This is very insightful. I'll let AI take the whole job, if it means it will just do whatever I want after. Small loss if that means lots of programming jobs disappear.

Your opinion is more about magic than computer science.

You know the quote I'm going to put here :)

Hey you're right, a language shouldn't let me just describe what my executable should do - and then give me that executable. My mistake!

A language should just be a super tiny syntactic framework that elegantly lets library writers rewrite the same thing they already wrote in C++, Python, Perl, Go, Java etc libraries for - but this time in my language!

It shouldn't really "do" anything. Who needs a programming language with any abilities! That's not what languages are for!

/s

> A language should just be a super tiny syntactic framework that elegantly lets library writers rewrite the same thing they already wrote in C++, Python, Perl, Go, Java etc libraries for - but this time in my language!

The rewrite issue is exactly why it makes sense to avoid putting things in the language if it doesn't need to be part of the language.

Consider that a more generic way of offering what you suggest is to punt most of it to the OS and have the language/runtime instead "just" offer you a way of having it pre-allocate sufficient space from the OS. Many do in some way or other, either by getting out of the way (e.g. C, C++, any other language with "manual" memory management) or by offering switches or known behaviour to coerce the allocators to act how you want (e.g. in most VM based languages you'll find options to tune the allocation/GC patterns in various way).

In practice there are ways of doing what you want in most language/OS combinations, if not always as cleanly as you might like. If you want functionality like that as part of the language, a more flexible approach would be to e.g. do things like support cross-cutting (effectively inserting hooks before/after function/method calls) or method/function aliasing and provide a means to switch out the object/memory allocator. Doing so would be far more generic, and would allow the functionality you want to be written as library code instead of adding specialised language construct for a specific memory allocation strategy.

Here's the problem with that idea: How do you convert your abstract high-level description into a set of specific operations? First you need to parse your specification, and parsing natural language is already hard. Secondly, you have to infer everything else that was requested and will be needed but was not originally specified.

Alright, now you have your list of requirements. Firstly, you must break each requirement down into a long series of small steps that perform exactly one operation - such as add 1 and 1 together. You must also find the correct order for all of the steps, as well as the operations to store and manage all required data in memory as meeded.

Finally, the list must either be translated to the native language of your computer's CPU or ran by a program running on the CPU.

As you can see, this is actually a large and difficult task, even if you manage to not encounter any unsolvable problems along the way. I would think the following comes naturally: The difference between your language and the 'dumb-as-rocks' ones is that the latter are implementable and usable.

>Here's the problem with that idea: How do you convert your abstract high-level description into a set of specific operations? First you need to parse your specification, and parsing natural language is already hard. [my emphasis]

If that were true it would be impossible to make a flow-chart based interface to a "compiler" that produces an executable based on the flowchart (without any keywords, variable names, etc). But plainly it is possible to make such a flowchart->executable compiler+visual IDE, so you are incorrect regarding the claim that the specification needs to be parsed lexically. Functionality does not depend on lexical parsing. It's that simple.

>It shouldn't really "do" anything. Who needs a programming language with any abilities! That's not what languages are for!

Everything you have available in software (and/or hardware) is the result of some of those languages that "don't do anything" and don't have "any abilities".

You want a "a language that lets [you] just describe what [your] executable should do - and then give [you] that executable".

That's exactly what existing languages already do -- the description happens in the language's syntax.

If you want a declarative description in physical language, you actually want a programming team, not a language. And the description is called a "design document" or "functional requirements".

You will get those when AI replaces programmers. And even then only as much as any set of loose language can be translated to a precise behaving program.

Don't hold your breath for either.

For all the misplaced sarcasm I don't think you understand how computers work.

I, and many others in here, can write a language like one of those you mention (Perl, C, etc). Can you write one like you described you want? You know, to show us all how it should be done, and how we're idiots for now offering it to you?

Reminds me more of those freshmen that hear about assembly being faster and want to rewrite everything, OS, apps, etc in assembly, because faster.

You can return to this comment in 20 years and compare the state of languages then with the features programming languages implement in 2017. Today it is my opinion that languages differ most markedly in their syntax and some of the primitives, but generally speaking implement largely similar functionality.

For this reason there are source-to-source compilers (transpilers) and it is very common to host one language in another, in the way that Wordpress was ported to .NET: https://news.ycombinator.com/item?id=13753445 The way in which this was done was to expand .NET to run php.

Languages just don't do very much today, in my opinion. Everything is hard. If you disagree with me then we ca return to this in 20 years and compare the state then and now.

I am not designing another language at the moment. The above is just my opinion.

> Whenever this function is called, make sure there is enough free memory ...

Lisp? Forth? Smalltalk? And that's just off the top of my head. But really, an operating system with a virtual memory system will handle that mess for you.

> analzye this library and include a logically simplified version that only needs to address these cases

I think SynthesisOS (an operating system, not a programming language) could pull that off to a degree (the kernel was JIT'ed and therefore, customized system calls could be developed).

> if variables A and B ever both change as a result of the same function call ...

I wouldn't be surprised if GDB couldn't do this. I know it can watch both reads and writes, so this should be possible. How easy is a different answer.

And you know, the best way to get to the future is to invent the future ...

> I think SynthesisOS (an operating system, not a programming language) could pull that off to a degree (the kernel was JIT'ed and therefore, customized system calls could be developed).

I keep meaning to spend more time looking at SynthesisOS [1] - it deserves more attention. The JIT'ing as a means to speed up system functions by specialising them could be useful all over the place, and I think one of the most important contributions is that it doesn't need to be done everywhere - you can specialise JIT'ing of very small portions of hot codepaths and get a lot of the benefit at very low cost.

For those not familiar with Synthesis, chapter 3 of [1] is a good place for a quick summary of the techniques used. Section 3.3.1 gives concrete examples.

(The old Amiga user in me is very pleased Synthesis used M68k - makes the assembler examples very nostalgic...)

[1] Synthesis: An Efficient Implementation of Fundamental Operating System Services Alexia Massalin - http://valerieaurora.org/synthesis/SynthesisOS/

If I remember well it had no memory protection, incompatible by design so..

The specific case of pre- and post- memory management could be handled by hooks (like in emacs lisp) or automatically through an abstraction along the lines of https://en.wikipedia.org/wiki/Resource_acquisition_is_initia...

I'd argue that some languages have some quite powerful syntactic conventions. Pattern matching and algebraic data types are very clear and concise (and statically-checkable) ways to write code. A whiteboard can't compete in the concrete case of covering all the possibilities and proving it. There's clearly more wit in those constructs than in a simple AST, which seems to me to contradict your claim.

Quick, name a language where I can do something simple like mention "Whenever this function is called, make sure there is enough free memory (at least ---- MB) before actually calling it; if there isn't, first swap out any objects from memory to disk, starting with the ones that had been used the longest time ago, and after the function has finished running, swap those back into memory."

Why would you need a language for that? Isn't memory management what a kernel will do for you, including this specific scenario (the swap back to memory part will be done if pages are needed in memory)?

Why would you need any new language? Likely anything you would want has been done in some language already.

I was simply giving an example of something simple and well-specified that isn't being done.

-

In response to the other comment (sorry this is breaking the comment ordering, but I am going to sleep soon and triggered some submitting too much message):

>And you know, the best way to get to the future is to invent the future ...

Nobody is going to accuse you of being an idea man/woman if you just stand around and wait. (My original comment was downvoted to -3, though this surprised me).

Meanwhile I can pick my battles (what to invent) carefully, away from the dumb as a sack of rocks status quo. Which I was just reporting a part of.

Don't shoot the messenger. (But also, as a practical matter, this story is about how syntax is the last thing you should design - which I kind of disagree with.)

-

I also wish I had added in parentheses (in my original comment) after "pictographic symbols", the words "(or evocative post-modern landscapes that have meaning only to you, the language designer, with a brief sentence underneath each one, of the type that if you were to ever revisit it or have to explain it to anyone else you could)" in parentheses, though now that I see the backlash against my comment, it doesn't really matter. The reason I can't add those parenthetical words is because I am outside my edit window.

> I was simply giving an example of something simple and well-specified that isn't being done.

But as has been explained elsewhere in this thread, it is being done, but either by the OS or the VM, rather than as part of the language semantics.

Improvements in the explicit handling of memory allocation are both possible and desired in programming languages (eg. Rust has some interesting memory-related syntax and semantics), but this particular suggestion of yours just isn't well thought out.

You picked one of three examples I gave - it doesn't matter if they were well-thought-out, I just gave three examples of things that aren't easy in any of the languages I code in. That's because every language I code in is ALMOST the same (there are translators that translate one to the other robotically, for example) - their biggest difference is syntax. Of course they differ a lot in their functionality - but none of them have much of that to begin with, in my opinion. Today's languages are tiny and hardly do anything. In my opinion. (Check this comment in twenty years and I think you will find I was right.)

> Quick, name a language where I can do something simple like mention "Whenever this function is called, make sure there is enough free memory (at least ---- MB) before actually calling it; if there isn't, first swap out any objects from memory to disk, starting with the ones that had been used the longest time ago, and after the function has finished running, swap those back into memory."

Can you imagine trying to debug a program that used such a language feature? What a nightmare.

Yeah it's a lot easier to reason about languages that are as dumb as a sack of rocks - they're so well-defined!

Basically just syntax. Add a bit of syntax highlighting and you know EXACTLY what's going on.

Which is my point.

I look forward to languages that make it trivial to do super hard stuff. If debugging them is hard, make it easy to ask them what's going on. (Also difficult today, again, because they are as dumb as a sack of rocks.)

Every example I gave was super well-defined.

Sure it is well defined, but the resulting performance of the program isn't necessarily deterministic, it will be super sensitive to whatever else is going on in the machine as well as whatever else the program is doing.

Why would you want to add a syntactical feature that duplicates the services the OS is already providing and makes the performance of the program less predictable and consistent?

"I'm going to remodel my nasal cavity to accommodate a swarm of bees" is a well-defined goal - it just isn't something you'd want to do, even if you've got access to tooling that makes it straightforward.

> Quick, name a language where I can do something simple like mention [...]

Every single language out there is capable of doing all these things. Like, even Python fits the bill:

> Whenever this function is called

Use decorators to add pre and post processing to any function.

> make sure there is enough free memory (at least ---- MB)

Call out appropriate OS function (http://stackoverflow.com/questions/2513505/how-to-get-availa...) via ctypes. Or use Python's own `gc` module, if you're only interested in your process' memory.

> if there isn't, first swap out any objects from memory to disk

Use `pickle` to serialize your objects, use advanced meta-programming to create proxies for the serialized objects which you can then use (store in dicts, list, pass to functions, etc.) which defer loading from disk until needed again in the future. Remember to initiate gc cleanup after you're done dumping things to disk.

> starting with the ones that had been used the longest time ago

Store access time on objects, sort by that time when serializing.

> and after the function has finished running, swap those back into memory.

Touch every proxy object so that it reads and unpickles the object it replaced earlier.

--

So, let me repeat: every existing language lets you do all of that and more. The amount of work needed to make all these differs by language, of course, but you can do all that if you want, in any language you choose.

I don't know what you're thinking. Given that the above is obvious to any competent programmer, could it be that you're a simple troll?

Everything you said is much more complicated than the simple directive I gave (as an example of functionality).

You should not accuse others here of trolling, you can read the guidelines here:

https://news.ycombinator.com/newsguidelines.html

Please be civil on HN.

I further gave you an extremely difficult functionality, which I phrased as " 'analzye this library and include a logically simplified version that only needs to address these cases:' (a list of conditions.)". You ignored this.

This is obviously not functionality any language includes. It is not easy or anything like that.

If you don't like my examples, you can come up with your own. Pick something hard that programming languages don't do.

You are correct that most programming languages have most of the same functionality, and differ only in their syntax: this was my point. For this reason there are transpilers (source to source compilers) which output a different language.

If you don't like my examples, pick your own. Anyway in this comment I have already quoted myself saying such an example, which you ignored.

My overall point is that most languages don't strive for such features. They most markedly just differ in syntax. You confirmed this at the top of your comment.

Thanks for your additional thought, and please remember to be civil.

> Please be civil on HN.

Please don't use phrases like "dumb as a sack of rocks" when referring to someone's work.

Such a waste of time...