civility

> So, if we attempt to create a Frankenstein language that combine concepts of bash and C, which set of programmers do we inconvenience with the noisier syntax?

I won't speak for others, but I can make that choice for myself, and I'm willing to give the C-like language the upper hand. If bash like things were high enough priority, I might change the name "system" to "run" so it was just a bit more concise, perhaps taking multi-line strings to tidy it all up. I'm not saying one language to rule them all, I'm just saying I could have one language for nearly everything I've done or want to do.

What I was talking about was more like what features does the language have. For instance, I like algebraic data types (sum/product types). I like generics/templates. I want an "any" (variant) type. I want complex numbers and matrices. I like operator overloading so I can implement new arithmetic types. I want simple and immutable strings. I want structs and unions. I want SIMD types. I could also list things I don't want.

Anyways, I could go on, but all of those fit in a single efficient and expressive language. Some current languages come close, but get important details wrong.

> I also don't see how one language can offer both garbage-collected memory and manual allocated memory using convenient concise syntax _and_ and zero-cost runtime performance-penalty for manual memory. Those two goals contradict each other.

There are a lot of details that matter, and I can already anticipate some of your objections, but I would be very happy with automatic reference counting on a type system which precludes reference cycles. I would not use atomic increments or decrements (which is one of the more costly aspects of reference counting), and I would not let threads share data directly. This provides deterministic memory management and performance not too short of what you get in C, C++, or Rust.

So not "zero-cost", but damned close. It's also simple enough to think about the implementation so you can easily keep the non-zero-cost parts out of the inner loops.

Of course someone else would disagree and say they can't accept this (minor) compromise.

Ousterhout had a famous quote about needing both a high and low level language. For him, that was Tcl and C. I think I could have everything I need/want for high and low level tasks in a single elegant language. You're not alone in disagreeing :-)

> I have implemented language VMs and garbage collectors where I needed to work at the level of raw bytes and manual memory management

Fair enough, and I guess I'm forced to agree a little. However, if the one true language already existed, the VM/GC problem wouldn't have to be solved twice. Somebody had to write the first assembler in machine code, too.

I've written a (Hans Boehm style) GC of my own, and I admit that wouldn't fit with what I had in mind either, but working with raw bytes is a solvable problem in almost any level of programming language as a few library functions. All the batch or command line utilities, GUI applications, back end server modules, and most of the one-off exploratory programs could fit in a single elegant language.

> I like static types for decent-sized programs, but I also use config files and other "data languages" where that would be more frustrating than anything.

Again I agree, but (to me) this has a solution. I could be very content with a statically typed language with a single variant type for when you need to handle JSON-ish type dynamic variables or hierarchical data. I think dynamic and static typing can coexist very nicely in one language.

> Even if there was a single language that was perfect for me for all of the code I write, I don't expect that that language would be perfect for others, and I don't think those people are wrong.

I did caveat this was for single person programs and that different people would make different choices. I think my point was just that, having looked at languages from Icon to Prolog to SQL to Scheme to Ocaml to Rust to C++ and a lot of others, I think there is a point in the high-D trade space where I would be content to live and breath for almost every programming problem.

I've never gotten anyone else to agree, but I think it's an interesting exercise to fill in the details. I mean, computers are so much malleable than real world tools - you could have a single thing which handles screws, nails, rivets, and bolts effectively.

> I can't point to a single language that I would prefer for all of the different kinds of programs I've written.

I never liked the "pick the right tool for job" cliche in the context of programming languages. I'm curious if you can imagine a single programming language which you /would/ prefer for all of the different kinds of programs you've written. Not that it does exist, but could it?

Other than size, weight, power, and price limitations, I don't pick different computers for different problems. I mean I could live with one ISA for pretty much everything, including GPUs. I'm sure different people would pick different answers (one of your points), but after looking at a lot of languages over the years (including some of yours), I can't come up with two features I want which are inherently in conflict and necessitate being different languages.

I don't think it has to be a superset of all languages monstrosity either. And for the sake of argument, let's say this is just for one-person development. There's too much politics in trying to decide what features you /don't/ want your coworkers to abuse. :-)

Interesting. I'm not familiar with "pic", but I'll check it out. I've never seen a manpage with that in it.

A terminal with graphics in it would be nice too. Maybe if Tek4014 (and the Tek emulation in xterm) had graphics and useful text simultaneously it would've been more popular than the modal approach. I've also heard of Sixel, but never seen it live.

Yeah, I'm guilty of being pretty cynical/pessimistic from time to time too. However, despite all the nastiness and privacy invading features of the technical world, a lot of things really have just gotten better over time. Maybe just don't run "Braindows 10" or "BrainOS X" with automatic updates.

> eyes are deep into both the design and the construction of the brain. Sooo, super tough to have a better intake channel.

Maybe the optical processing parts of the brain are where they'll inject a lot of the new interfaces. Have you ever had the sensation, when you're really focused on a problem and thinking hard about it, of not being able to see while you're concentrating? To me, it feels like your brain is /borrowing/ the optical lobes for other purposes at that time. I don't have any background in neurology, but it's fun to think about regardless.

Stross, yes. Not sure if it was book 3 of a series or something. I didn't read much else of his.

I agree.

If you like science fiction at all, give Accelerando a read. Of course it's just a story, but it feels like a possible real future (at least the first section). In it, there is definitely a place for people who reject integrating with technology, but that place is in the back and left behind. Instant access to all of digital knowledge, unlimited storage for every thought or experience that interests you, performing complicated calculations, visualizing higher dimensions, and so on. Your fingers, ears, and voice aren't that quick, and your eyes are limited to 2D and only have decent resolution around the center. There is certainly room for improvement over what evolved in mammals (or any animal).

It probably won't be real before I die of old age, and I'd certainly let the early adopters find the bugs, but sign me up for version 3.0 or later if I'm still around.

Tough to say what counts as large, but there are lots of articles like this one about avocado growing towns hiring their own militia because the federal government simply isn't relevant in the area:

    https://www.nytimes.com/2018/01/07/world/americas/mexico-state-corruption.html

It sounds a lot like local patches of plutocracy to me.

True Scotsman have a very low mortality rate.

To be fair, I think qualifying as a tourist is much less subjective than being called "good". As non-native to Mexico, I really am more interested in the probability "being murdered in Mexico given you're a a tourist", P(m|t), than "being murdered in Mexico", P(m).

SVG could work (if you can stomach XML). The great thing about standards is there are so many to choose from.

How about 3 fonts (serif, sans, and fixed) and color instead of monochrome? You're too quick to compromise :-)

Vector graphics would be adequate and could discourage huge binary dumps in the code, but you know someone would try to jam a photograph in there by inserting a square per pixel, and I can't really blame them. Postscript could work, but if you picked something explicitly line oriented it would cause less confusion in revision control.

I should check out org-mode. It's been more than 25 years since I used emacs with any regularity.

> Theoretically there's a process for requesting new software and getting it approved, but actually pushing it through requires getting one of my program architects to care enough to file the request

I worked for a much smaller government contractor, but before I left they were moving to a system where you needed approval from the customer in order to get new packages. (For those who don't work in this field, that means you are actually making a request to the contracting representative from the particular government agency for each package you want.) So it wasn't just in-house bureaucracy in the way of progress, and I generally just went without or wrote my own instead of trying to deal with it.

I think one of the most amazing parts of Racket, and one of the reasons someone should try it out if they haven't, is that the source code and evaluator support images and not just text. The following link shows one aspect of this:

https://docs.racket-lang.org/quick/

Just being able to put an image in a comment explaining your algorithm into your code would be huge improvement over the traditional syntax colored ascii you get with most languages and editors. There are many times I've written an algorithm which is difficult to understand without the associated diagram I drew on the whiteboard or in an image editor. Racket lets you insert that image or photo directly into your source, and I think this is a significant improvement over putting a link to that image in a comment.

Racket also goes a step beyond that by letting images be values which can be assigned to variables or returned from functions. The link above shows this clearly. I'm sure there is some value in this as a teaching aid, and I think that's why they did it, but you can also return mathematical plots from your functions and so on. This feature is similar to the various interactive notebooks people use for Mathematica or Python, so it's not really specific to Racket, but it is interesting to play with.

Obviously there are downsides to putting images in your source. After you do that, your code is no longer ascii, and it won't be something you can edit with vi, emacs, or any non-Racket IDE. Also I doubt it will play nicely with git any time soon. However, it's a neat feature of Racket whereas many of the other benefits in the article apply to any Scheme (Chez, Gambit, Chicken, Guile, etc...) or lisp.

I wish there was some reasonable standard (like a better version of Rich Text) that was commonly adopted so other languages could put graphical pictures in the source code.

> Speak for yourself, and find another platform for arguing about Python and Nazis.

You're the jackass who brought Nazi's into a tech conversation, and you're also the one who brought Python into the conversation. As for telling me where or what to argue, you don't really have any authority in the matter. We can add this to your other weird delusions.

> I keep finding I need to repeat myself

Communicating with people is hard, especially when you only really want to repeat yourself and not try to understand what anyone else is saying. I get your point - fork is slow. Now what do you think my point was? Please don't bother repeating yourself again.

First you say I'm a bash apologist and then a Nazi apologist. Where is a philosophical Python criticizer supposed to go in order to get a fair shake. You can do better than ad hominem rebuttals.

Ugh, you edited a bunch while I was replying again. I can't keep up. My only point had been that Python is also slow.

> Nope, Python's Tkinter canvas calls into TCL/Tk directly. It doesn't run it as a separate process. There is no comparison: Another false equivalence.

Python's Tkinter converts all calls into strings which are parsed and executed by the hidden Tcl interpreter in there. It's really pretty hackish. I didn't say it ran in a separate process, I said it was probably on par performance-wise as bash calling gnuplot through a separate process.

> Can you integrate C extensions into bash with SWIG, or any other way short or recompiling?

Yuck. Why would I want to do that? I don't like SWIG or bash. SWIG generates an awful mess. When needed, I prefer to write Python extensions by hand.

However, I suspect the only reason bash doesn't support plugins/extensions has more to do with some GPL ideology.

> You keep going back to this mistaken belief that forking off separate processes is incredibly cheap. Or even convenient. You really should rid yourself of that misconception.

You should really stick to things I've actually written. I'm starting to think you're having an argument with some imaginary bash and fork advocate in your head and pretending I'm him.

Heh, you edited significantly again while I was replying. It's tough to keep the conversation coherent when you do that.

Thank you for the link. I'll give it a look.

> While you're farting bubbles in the bathtub about integrating "bc" into bash, and haven't even proposed how you'll integrate the canvas api yet.

I tend to fart in the shower, and I don't give a crap about bc or bash. As for the canvas api, you must've missed the part where I said you can call gnuplot from bash (or any language which supports fork, dup, and exec, or popen). I'd guess that bash calling gnuplot as a subprocess is on par with Python calling the Tkinter canvas through their hackish hidden-Tcl abomination. You're probably a matplotlib guy though...

Incidentally, I have built command line plotters before, but I can't share the code, so you don't have any reason to believe me on that.

> Even Michael Godwin says there are times when it's acceptable to compare shitheads to Nazis

I wonder if we were in our early 20s during Nazi Germany if either of us would have the wherewithal to reject being a Nazi. I suspect we're all shitheads depending on the context.

> I'm dis-recommnending bash.

Yeah, I got that. I just thought it was absurd for you to only aim for a few orders of magnitude speed improvement when you could've easily gotten several more by arguing for something faster than Python.

> You admit floating point math in bash would be a good idea, and you seem to think [...]

You're doing that thing again where you try to represent my argument for me. This time instead of telling me what I might say, you're telling me what I think. You're wrong again, and it's still a poor argument strategy.

I'm not defending or advocating bash. I'm certainly not recommending any improvements to it - I only said they were possible. I am however calling you out for recommending Python in any case where performance matters.

> The Nazis and the Anti-Nazi protesters were not of the same order of magnitude of evil in Charlottesville

Are you intentionally invoking Godwin's law because you know your argument is untenable?

> PyPy is a thing, and it works just fine, you know

I like PyPy. It's not perfect, but it's pretty good. Maybe you should recommend that in the first place next time.

> But it's IMPOSSIBLE to implement a bash JIT compiler [...] to fork "bc"

Never say never. Before V8, everyone thought JavaScript had to be as slow as Python too. Now we have PyPy and LuaJIT, which I would've thought were impossible.

> And no, integrating "bc" into bash isn't a valid solution, or they would have done it ages ago

You seem really hung up on "bc". You do realize that "echo" wasn't always a builtin, and that they added it for performance reasons, right? If anyone cared enough, they could add "bc" as a builtin. Hell, the expression evaluator for integers is well on it's way. You're right that probably nobody cares enough to build in "bc", but I wouldn't be surprised to see a triple paren or square bracket math interpreter with floating point support in bash someday. Heh, maybe they'll even add complex numbers. And a bash JIT is exactly the kind of thing some grad student would do for the absurdity of it all.

Ahh, you edited significantly while I was replying. Here goes to your current message:

> [...] you ask "Why would I ever want to calculate a cosine in a bash script?"

I wouldn't ask that. This kind of argument strategy is silly too. You should choose your own words, and I'll choose mine. Leave the fake dialogs to Aristotle.

> To illustrate my point: Perhaps you want to write a script that draws a pie chart to illustrate your disk space. With bash, you'd have to call out to another language to do that. Why is that? Tell me why hasn't anyone come up with a way to draw like the canvas API in bash, without forking off dozens if not thousands of processes? Don't you think that would be useful?

I routinely use gnuplot as plotter in a child process. This works with bash, python, C++, or any other language which supports popen (that's fork, dup, and exec).

> Because bash can't even perform the simplest APPLESOFT BASIC floating point math operations [...]

I'm not defending bash. I'm saying that putting Python much ahead of it is silly. Why would you want to run a race with either a snail or a turtle? Silly parables about the tortoise and the hare aside, pick a cheetah or something.

> And of course needlessly converting all those numbers back and forth between strings and floating point so many times.

Python tediously checks if the vtable contains the necessary operator, evaluates the function pointer it finds, which checks the other operand's type, unpacks the 8 bytes of doubles from each 32 byte struct, finally performs the operation, then allocates a new 32 byte structure for the return result, which is checked to see if an exception occurred, and then pushed onto the stack. I probably missed some steps, and I certainly ignored the sophomore level interpreter loop overhead.

I mean, yeah that's faster than fork, but I'm not sure it's a huge win over anything else.

> Thanks for illustrating how some people still completely miss the point.

You're being feisty, whatever.

> We are discussing the overhead of forking processes to do math, which Python doesn't have to do.

Python uses dynamic dispatch on boxed types for every single operation. You're right this /only/ takes hundreds of instructions, but that just shows my analogy is appropriate. That's the turtle, in case you didn't understand it. I think it's silly for you to say this is "tolerably slow" for anyone but yourself. For other people, a fork per operation is completely tolerable. (I'm not one of those people...)

> [...] explain how a bash JIT compiler could optimize out all the instructions necessary to fork "bc" to call the cos instruction.

If anyone cared, bash could implement "bc" as a builtin the same way it does "echo". That'd be ugly, but it seems like the kind of thing the GNU folks would do if it was a common enough use case.

> the coding style used seems to lend strongly towards not thinking an error is possible

So does every tutorial which doesn't check the return from printf or check for errors from cout. Did you notice that the parent and child are both writing to the same file descriptor? Maybe the writer should add some words and tests in his code about the inherent race condition there. A true pedant would push this even further and teach their audience how to eliminate this problem with cross process mutexes or semaphores. Better be sure to check the error codes on those calls too.

I know arguing with a pedant is like wrestling with a pig, but honestly I'm more offended by the "#define N 2" than by the lack of error checking.

Promoting Python over shell scripts in the name of efficiency is silly. It's like saying you should prefer turtles instead of snails.

I wouldn't criticize anyone for posting code snippets for educational purposes without confounding the learner with all of the error checking. Pedagogy vs pedantry.

> Having run up against limits of the Python standard library several times in years of writing production software in it and not just learning it, I find the batteries-not-includes-but-easy-to-install approach better on the whole.

Obviously it doesn't apply to everyone, and it certainly doesn't apply to most startups or open source developers, but I spent most of the last 20 years working in environments where you have to get permission for every third party library you bring on to the network. Many networks were essentially "airgapped", so it's not like you could just ignore the rules. The bureaucratic process alone meant that we preferred large bundles like Anaconda or Qt. Trying to use Cargo as it is typically used and documented would be a complete non-starter.