Hacker News new | past | comments | ask | show | jobs | submit | seabird's comments login

People say this to feel better about the situation with zero regard for the insidious societal issues it causes. It's absolutely true but it's basically never productive to make a point of it. For your own good and the good of society, develop more helpful insights or don't say anything at all.

Going through life with basically zero romantic opportunities will completely fucking fry the brain of an average human. Sex, romance, etc. are a top psychological priority to ensure the continuation of the species and most people on this planet are hardwired to be in pain in the absence of it. With some luck, people hurting like that hold on to some hope of things changing for them and it provides enough motivation to break even on societal contribution.

If they give up hope, our society is structured in a way that doesn't give them any reason to play by the rules any more. If you're holding down a good job, blow your money on stupid shit; you have no wife to disappoint and no kids feed. If your hobbies consist of jacking off and playing video games (these are super easy, so you should definitely consider them) just half-ass whatever job lets you squeak by on rent if you're not fortunate enough to crash at your parents' place indefinitely. Get super into drugs, you're not really hurting anybody but yourself. Your friends might think you're a fuckup, but they're busy with their family and don't have a lot of free time to spend with you, so you don't have to be ashamed of your situation all that often. 30+ years of no responsibilities other than don't die (and even that part is kind of optional). Gonzo lifestyle. It's all yours, baby. It's lit.

There are people out there that are just plain bitter, unstable, unable to be reasonably loved, and maybe even ugly to boot. There's not much to be done about that. That being said, in the modern era, it is very possible (maybe even easy) for good people to never form any romantic relationship that would tie them into productive society, and turn into burnouts with apathetic, bitter worldviews. "You aren't owed anything and you got what was coming" is not encouraging in the slightest.


PFOF is not front running. Market making is not front running. Full stop. This fact is only controversial if you fundamentally misunderstand what market makers do.

There's a middle ground between the Apple model and assembling everything yourself.


>Who is more likely to lobby my government to adverse affect?

Dude, the concern is that allowing TikTok is quite literally allowing the CCP to indirectly lobby. It's how this whole thing got started in earnest.

https://www.nytimes.com/2024/03/07/business/tiktok-phone-cal...

The geopolitical utility of the app is to give the CCP more power to manipulate and hurt you. They want to get closer to the level of power that domestic US powers-that-be have. I'm blown away that this seems to lost on so many people commenting here


Maybe my interests and those of the general American public are more in line with the "CCP" than Israel regarding international affairs.


Putting CCP in quotes is silly. It is not a conspiracy theory that the CCP exerts an extreme level of control over ByteDance.

Your interests are probably not aligned with the CCP. The American public's certainly aren't. The Chinese government wants to achieve a hegemony and export their economy and culture by undermining the US wherever they can. We don't fit into that in a way that won't result in a markedly worse life for us.

TikTok would boost content about how Israelis making target practice out of Palestinian children is great and needs to happen more often if it made the US look bad. That you can't see that, or can't separate that instance from other possibilities, is exactly why TikTok is under scrutiny.


It's in quotes because the actual English initialism is CPC.

Using "CCP" shows your ideological bias.


You say that like CPC doesn't carry an ideological implication of its own. To the average person, the distinction between calling it the Chinese Communist Party and the Communist Party of China is so miniscule that they're not going to seriously engage with you if you earnestly try and take that angle. Go ahead and nitpick over how people refer to the party at your ideology's expense. I sure as shit won't stop you.


It shows that you make no effort to get non-US media and don't have informed opinions.


I make plenty of effort to stay informed, I just don't make any effort to argue inconsequential shit to signal that I'm "more informed". At some point in this conversation, you just quit addressing anything other than what you believe to be the most accurate initialism for the Party like anybody cares. You're either deflecting or are arguing silly points for the love of the game. If you genuinely believe what you're implying you do, you're actively repelling people from your ideology.


This is a result of Taylorist management brain rot drive to reduce drive thru wait time metrics at the expense of anybody not in the drive through. Watch the shot clock near the drive through window (they're highly visible at Taco Bell) and observe that drive thru customers almost never wait more than 60-80 seconds.


American gun control discourse basically completely ignores the reality that a huge amount of it is driven by gang violence and criminality. It is focused almost entirely on school shootings and things that suburbanite white people are afraid of. You're correct, they are mass shootings, but so many people aren't actually interested in stopping mass shootings on the whole, just the narrow class of them that may affect them.


I've seen a single company that does warehouse management software out of Sweden that advertises (in job listings) that they're using it. Otherwise, it's pretty slim pickings if you're not applying in its wheelhouse (high integrity systems -- aerospace, defense, medical, etc).

If you do microcontroller firmware development, I'd say it's perfectly reasonable to float it for a smaller project and just give it a spin. The language is significantly more modern/sane than C so you're not really exposing yourself to much talent risk. There's no gaping holes in the environment, experienced firmware devs will adjust easily, and new devs will feel more at home with the facilities provided.


What was the company in Sweden? Thankfully I live in Stockholm!


I think that'd be Lund Sweden, or Consafe Logistics. Similar systems at both.


Consafe was who I was thinking of.


Ada is a criminally underrated tool that is unfortunately probably doomed to perpetually take the backseat to Rust despite Rust not solving all the problems Ada does. It's really sad that so many people's idea of safe programming is pretty strictly limited to memory safety, and that because Ada's baseline memory safety (SPARK is a different story) isn't as robust as Rust's borrow checker (in the sense that it doesn't have a borrow checker in favor of just avoiding dynamic allocations whenever possible), that it's a relic of the past.

Ada's type system, SPARK, general clarity on behavior, etc. allows you to structure programs in a manner that makes it hard to Hold It Wrong, especially when dealing with embedded firmware that has all sorts of hardware gotchas. I haven't gotten the chance to use the Tasking primitives in anger yet, but I have a strong suspicion that they're going to bail my ass out of a lot of problems just like the rest of the language has.

My team started at a new employer and made the jump from C to Ada for MCU firmware. We control things that spin real fast and our previous experiences with C definitely resulted in some screwups that left you weak in the knees for a bit. There was some initial hesitation but nobody has any interest in going back now. Rust was floated but we're all glad we didn't opt for it -- memory safety on a system that never allocates memory doesn't hold a candle to Ada's bitfield mapping/representation clauses, ranged types, decimal types, reference manual, formal verification options, concern from the powers that be about providing a stable and trustworthy environment for doing shit that you really don't want to get wrong, etc.


Ada is a lot of fun and a great thing which is ruined (and blessed) by the fact there's de facto only one implementation and company behind it out in the open, and that is semi-closed / license PITA. There were improvements over the years by AdaCore, but I think this altogether hurt the adoption of such a great language in general - no other wide open implementation (like Rust has). If you want to see an extreme example of such a hurt, take a look at Allegro CL and Franz; Imagine having that out in the open and what it'd do for CL, but at least CL has great alternatives in the open like SBCL, whereas Ada doesn't.



> out in the open

This part was an important part of the sentence you might've missed.



The original point is that there is only one open implementation. This is a link to that one open implementation. You are pushing this conversation around in circles.


How many open implementations are there for plenty of other languages, like the main implementations, driving the whole ecosystem, not partial implementations with if and buts?


How many open implementations are there of Rust?

(Serious question; I genuinely don't know. Always assumed it was about 1, though.)


Only 1, additionally there are two competing ones based on GCC still WIP, and an alternative backend (Cranelift) without the capabilities LLVM can offer in performance.


Do they all support the latest standards ?


A couple of them do, it isn't as if C and C++ FOSS compilers do as well.

https://en.cppreference.com/

C++23 and C23 are the latest, and there are plenty of missing features from previous standards.


It's FOSS and is actually included with GCC, but the toolchain is still a PITA to install just because no one (other than Debian and Arch Linux) bothers packaging it. I think Alire is supposed to make it easy to install but I haven't used it much: https://alire.ada.dev/

SPARK 2014 itself is the same too AFAIK, the problem is there's a lot of auxiliary static analysis tools and plugins that are gated behind AdaCore's sales wall (and of course they'd never deign to sell licenses affordable to individuals)


The situation was pretty bad a few years ago, and the licensing was confusing but it's pretty straightforward now with Alire. (AdaCore also got rid of their "Community Edition which had the weird license restrictions).

I'm doing a presentation at FOSDEM next year called "Get started with Ada in 2 minutes or less!"[1]; because (on MacOS and Linux) I can go from not having no toolchain a all to compiling hello world in under 2 minutes (I've timed it).

Here's some steps:

1. open your terminal, run the following command: curl --proto '=https' -sSf https://www.getada.dev/init.sh | sh

Congratulations, you now have Alire!

2. Run the following command: alr init --bin hello

Now you have a fully structured Ada project, gpr files and all!

3. Edit your program in hello/src/hello.adb

You can use vscode to open the hello folder with the Ada Language server, or just run "alr edit" to open your editor with all of the files built in.

4. Compile with: alr build

Alire will automatically grab the latest native toolchain (gnat, gprbuild, etc) and compile the program.

If you want to use another toolchain, such as for cross-compiling, or another version of GNAT, simply run: alr toolchains --select

5. Run the program: hello/bin/helo

On windows, you can just download the windows installer; alire is also on Freshports for the BSDs.

[1] https://fosdem.org/2025/schedule/event/fosdem-2025-5056-get-...


Your step 1 violated my very hard rule against piping curl into a shell.

…and is ironic advice for a safety-critical system, no?

——-

(Yes, I’ve read arp242.net/curl-to-sh.html - but my point being that as I’d be new to Ada then I don’t know who to trust; I’ve never heard of getada.dev therefore I don’t trust it)


It's an understandable rule, and you can definitely just download the binary from alire.ada.dev and add it to $PATH but with such a harsh stigma around how difficult it is to get the toolchain set up, GetAda follows the precedent of Rust, where you can grab the toolchain via "curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh" (thanks to Rustup).

It was received positively at the time:

Show HN: Getada: rustup-like installer for Ada's toolchain/package manager 194 points | 115 comments: https://news.ycombinator.com/item?id=40132373


Is it really so bad to run it twice, with cat/bat replaced with sh on the second pass? If you're really paranoid about it you could save the first run to a file, so you know for certain that the server didn't do a switcheroo for the second one, but if you think about it, that's a low-payout move for Bad Guy #N compared to just sending the pwnage the first time around.

This is beside the fact that we're talking about downloading and running a user-owned binary, which, unlike the shell script, is impractical to inspect in any detail, and has the same privileges as the shell script we're supposed to worry about.

I view "don't curl to shell" as about 90% theatrics basically. Sure, read it first, I do in fact do that. But it's a silly 'very hard rule'.


I routinely save to a file before execution, but it's not really about being attacked. It's about the fact that those scripts, in order to be "fire and forget", make many assumptions, often very large ones, about where I want things or under what user, etc.

Many of them are actually quite well-written under the hood and can be easily moved to other directories, have comments about what it is doing, etc.


Here are the Rust installation instructions, that apparently is sooo much better,

https://www.rust-lang.org/learn/get-started

> The primary way that folks install Rust is through a tool called Rustup, which is a Rust installer and version management tool.

A couple of lines below

> curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh


I'm pretty sure that gentoo also packages ada, but it doesn't get installed by default, as its behind a USE flag.


As far as I'm aware, the compiler AdaCore sells is just GCC. You can install GCC built with Ada support from your distros package manager and it will just work. You can also download builds from here: https://github.com/alire-project/GNAT-FSF-builds


> As far as I'm aware, the compiler AdaCore sells is just GCC.

The compiler yes, but I'm convinced FOSS gnatprove must be outdated in some way: Last time I tried following AdaCore's SPARK manuals, certain basic aspects and pragmas didn't work correctly on the latest version.

Not to mention when SPARK aspects sometimes broke the LSP and formatter.


If something hasn't changed, FSF builds are a year behind libre version (by design), and libre version is GPL3 cancer which is not suitable for commercial development. You're then stuck either with a year old version or buy into AdaCore Pro version of it. Not great, not terrible.. but that's kind of the only game out in the open, which is what makes it different from most of other languages out there.


GNAT CE isn't a thing anymore, only FSF and Pro exist. And AdaCore now sponsors Alire, which installs FSF GNAT, and relicensed some of their tools more permissively.


Haven't looked in a while. That's great news then! Rust steals a lot of thunder these days though.


> and libre version is GPL3 cancer which is not suitable for commercial development.

YTF would GPL v. 3 be "cancer" for commercial development? (Shades of Ballmer; is Linux also "a cancer" to you?)

EULAs have all kinds of stupid shit in them already. Just make yours GPL3-compatible.


Why would the license of the compiler matter? It doesn't require you to license the code you compile with it accordingly.


runtime matters


Why? The code you compile isn't infected by the runtime license?


???


> no other wide open implementation (like Rust has)

So (at least according to pjmlp in https://news.ycombinator.com/item?id=42548360) Rust also only has a single "wide open" implementation.

Which means Rust doesn't have any "other" open implementation either, right?

Honestly, it's hard to know what of all the pro-Rust stuff one sees (here and elsewhere on-line) to take seriously, when its advocates constantly -- consciously or not -- exaggerate its virtues like this.


Yeah, to this day Ada, though a beautiful language, is a hard choice to make if you are concerned about certain targets. How would i get my program to compile to Android NDK? Even Swift has a better story with it's tooling.

That's before we even talk about important stuff like libraries.


Unless you are using the Android NDK with the official provided clang for C and C++, anything else is a pain for masochits that rather endure yak shaving the whole infrastructure than code in either C or C++ alongside either Java or Kotlin.


What are the options required to build an android gcc these days?


None since Google dropped GCC support, to anyone to do the work to make it work again.


The popularity of a programming language is not always about what the language offers. I would say a comprehensive, well-documented, mature set of standard libraries for its target audience is far more important (notable examples like R, Python, and Go). Last time I checked, Ada doesn’t even have a de facto, high quality TLS/crypto library, let alone various essential protocol/format codecs, yet the core team (AdaCore I assume) puts a lot of resources into offering a few sophisticated flagship IDEs that potential hobbyists would never use (they already have vim, emacs or vscode). I understand that as a business they have to sell something for revenue and they cannot sell standard libraries. So, that’s probably a dilemma that we cannot have the nice things for Ada to take off.


There's some thick bindings to libtls that coincidentally happen to be written by the author of the article. There's also some OpenSSL bindings in Dmitry Kazakov's Simple Components and some in Ada Web Server by AdaCore, although they're pretty minimal.

I think most applications of Ada are in embedded systems where you don't often want anything not in the standard library.


> I think most applications of Ada are in embedded systems...

Ada is heavily used and carries a historical influence not only with embedded software space, but also with hardware space: VHDL is one of the two major hardware description languages used in ASIC design and FPGA implementations. (The other language is Verilog, based on - you guessed it - C, because of its popularity.)

"Due to the Department of Defense requiring as much of the syntax as possible to be based on Ada, in order to avoid re-inventing concepts that had already been thoroughly tested in the development of Ada, VHDL borrows heavily from the Ada programming language in both concept and syntax." - https://en.wikipedia.org/wiki/VHDL#History


And databases on the software space, PL/SQL is heavily influenced by Ada, and pg/SQL is influenced by PL/SQL.


Also a package manager - Rust's is excellent and a huge reason to use it over C/C++. I see Ada has Alire but that seems like a fairly recent development and I don't know how it compares.


Very few of which are needed or even wanted for lower level mcu development. I assume when the gp was talking about spinning things they were talking about ESC software.


For what it's worth, many Rust developers (including myself) are also Ada fans.

Note that ranged types, decimal types, etc. can fairly easily be emulated in Rust, with what I find is a clearer error mechanism.

SPARK is, of course, extremely cool :) There are several ways to work with theorem provers and/or model checkers in Rust, but nothing as nicely integrated as SPARK so far.


I would quibble with the "fairly easily" part. It will likely become possible to make them as ergonomic as the Ada variety if Rust's const generic and constant evaluation facilities are extended far enough, but this would also open up the can of worms of essentially giving Rust the full capabilities of a dependently-typed language (at least in its compile-time subset), which Rust's dev community may not necessarily be OK with.


I'll grant you that Rust is not nearly as ergonomic as Ada in this domain, but doing it manually is fairly easy. Turning it into a library is a bit more complicated - these days, I'd do it with macros. Of course, making sure that the compiler knows about it for optimization purposes would require lots of const generic.


The real benefit of Adas typing is that it is so easy to utilise often preventing logic errors.


And this is definitely a strong benefit.

The benefit of Rust's typing is that (in the absence of `unsafe` or bugs in the compiler or stdlib), it's a simple theorem prover. Much less powerful than the theorem provers you can use with SPARK, but it's a start :)


Steve Klabnik (of Rust fame) wrote a (very generous IMO) article about Ada, interesting comparison: https://steveklabnik.com/writing/learning-ada/


It suffered from high prices in compilers when it had an opportunity, plus Modula-2 and Object Pascal being good enough for those that cared about safety on 16 bit home computers.

It also didn't help that the UNIX vendors that had Ada compilers like Sun, it was an additional purchase on top of the development SKU that already had C and C++ included.


I'm a bit disappointed that we've ended up with Rust in the kernel but not Ada. The kernel relies on GCC and there's already an Ada compiler in GCC, so it wouldn't require adding another compiler as a build requirement like Rust does.

There's a couple of major advantages that Ada could have in the Linux over Rust for safe drivers:

1. Having the option to use SPARK for fully verified code provides a superset of the correctness guarantees provided by Rust. As mentioned in the parent comment, Rust focuses purely on memory safety whereas SPARK can provide partial or complete verification of functional correctness. Even without writing any contracts, just preventing things like arithmetic overflows is incredibly useful.

2. Representation clauses almost entirely eliminate the need for the error-prone manual (de-)serialisation that's littered all over Linux driver code: https://www.adaic.org/resources/add_content/standards/22rm/h...


Agreed. It would also alleviate the maintenance issue as Ada was designed to reduce software costs. Realistically the obly way this will have any chance is if a few developers were funded full time to work on it. There seemed to be a few full time devs pushing Rust support and some drivers before it was taken seriously. Honestly Ada is the best language that I have seen for drivers and for network stacks or for registers received as bytes. Linux is missing out.


> 2. Representation clauses almost entirely eliminate the need for the error-prone manual (de-)serialisation that's littered all over Linux driver code:

Do representation clauses let you specify endianess? From a quick glance at that link it didn't appear so. I would imagine that invalidates most use cases for them.


You can specify endianness, but only over the entire record, not an individual field. The way it works is a little complicated: https://www.adacore.com/gems/gem-140-bridging-the-endianness...


Interesting, thank you. I think per-record is probably good enough for most applications, and less verbose than per-member. But it's not part of the language (that page calls it "implementation specific") and quite recent (that page is undated but references Ada 2012 so must be since then). It wouldn't have helped the Ada project I'm working on, which had an endianess crisis with serialisation a few decades ago.



rust is in the kernel to attract the young developers, which ada does not.


GetIntoGamedev is not old, he's in his 20's. The issue is, is that people are not prepared to trying something if it doesn't look like C or C++.


But he's one. See how many people are jumping on the rust bandwagon…


>ended up with Rust in the kernel but not Ada

Linus hated Ada. I suspect he doesn't exactly like Rust either but the Tribe is just too strong within Linux.


Do you have a source for that? I've found his remarks on Pascal and C++ but not Ada.


Linus' opinion on Ada (vs Rust):

> We've had the system people who used Modula-2 or Ada, and I have to say Rust looks a lot better than either of those two disasters.

https://www.infoworld.com/article/2247741/linux-at-25-linus-...


> I'm a bit disappointed that we've ended up with Rust in the kernel but not Ada.

Why? Do you program in Ada or Coq?

People can't be bothered to track lifetimes, what makes you think they are ready to track pre/post-conditions, invariants and do it efficiently and thoroughly.


Having the option there is good, even if not everyone uses it. The same thing applies to Rust.


For Rust and Ada in the Kernel they need to be accepted by kernel maintainers.

And seeing they can't stand Rust, when its constraints are much weaker than Ada.Spark what chances does it have?

To paraphrase some computer science guru: The cyclical nature of programming languages is all to blame on the collective programmers. Rather than being guided by mathematic rigor, they are guided by a fashion sense.


I never even knew that this "Ancient Language" had dependent types. Always thought it was a "modern" invention of snazzy newer academic languages like Idris, etc.

But, its easy to figure out why it didn't become popular. C/C++/any other top10 language all had free compilers available to everyone. Ada didn't during the explosive era of computing expansion. Also, not a problem nowadays with IDE auto-complete/snippets but the language was too verbose for older generation of programmers.


Verbosity was genuinely expensive at the time. Two ways: until the mid-80s, 5 1/4" floppies held between 100 and 250kB depending on format, so a program which used up three times as many bytes (I think that's a good multiplier from C to Ada) is making a meaningful difference for transfer, backups, storage.

What's probably more important is that 80 columns was far and away the likely maximum for a screen, and 40 columns wasn't unheard of. The word PROCEDURE took up 11 to 22% of the column width! This wasn't a show-stopper, Pascal uses a similar syntax (both of them derived from Algol of course) and was pretty popular, but plenty of people complained about Pascal's verbosity as well, and Ada is definitely more verbose than even Pascal.

The lack of autocomplete (even things like snippets were relatively uncommon) didn't help, but mainly, verbosity imposed real costs which are mitigated or irrelevant now.


You talk about C and C++ yet call Ada "ancient," C from 1969 and C++ from 1979.

Whereas Ada's first version is from 1980 and first standardised version (different to 1980) in 1983. Yeah, "ancient."


Memory safety and the borrow checker are useful even in the absence of dynamic memory allocation. This still doesn't bring rust and ada to the same place, but it is important to clarify that piece.


Spark supports borrowing which is easier to use than Rusts now. It also prevents memory leaks.


Ideally, Rust would start adopting excellent features like Ada's SPARK, and vice-versa Ada get inspired by Rust's good parts as well.


> We control things that spin real fast and our previous experiences with C definitely resulted in some screwups that left you weak in the knees for a bit.

Ha, you could almost read this as a stuxnet joke


The literally verbose syntax contributes to its unpopularity as well. It is extremely hard to skim/read and comprehend prose-like Ada code.


For me it's the other way around, I can skim a program written in Ada and figure out what it's doing almost the immediately because it is highly structured and enforces correctness with no ambiguity through its syntax.

I can't really do the same for rust which tends to lend itself into a more confusing format.


About two years ago, I was able to dive into the Ada reference manual formatter which has initial commit of March 2000 and is about 45k lines of code, and add MDX output pretty easily.

Other languages focus on terseness and expressiveness. Ada expresses a bunch of constraints directly and forces you to do things in organized ways (e.g. use namespaces appropriately).


Wouldn't Rust's symbol heavy syntax contribute the same?


I think that since a significant portion of Rust developers come from a C++ background, and C++ uses basically the same set of symbols, it's not a huge barrier to adoption


Rust actually has a bunch of oddities, to the point they test them [0].

[0] https://github.com/rust-lang/rust/blob/master/tests/ui/weird...


There's really only one sigil in there that isn't in C++ (the ' single-quote to name lifetimes and labels). And it's missing several ambiguities that plague older C++ grammars (i.e. is >> a greater than, or closing two template expressions?)


> (i.e. is >> a greater than, or closing two template expressions?)

I thought it was a pointer-dereference signifier(, or maybe an object-string-stream thingy)? If you mean C++, that is.


I like Ada, but I tend to agree. "End Something_Somethig_Something" is really a mouthful (compared to "}"). And programmers are superficial like that. Ada wouldn't be the first decent language being dismissed for inconsequential aspects like this one.


Context free curly braces in deeply nested code make me crazy. Labels to match up with the open symbol would be super helpful.

My company’s style guide requires them on closing braces for namespaces.


Let me say that I do agree with you.

However I’d add that this job could easily be done by the IDE. For a reason that I fail to grasp, after being around for multiple decades, IDEs are still incredibly bad at presenting useful information on the code. Apart from coloration and more recently type hints, there never have been any real innovation in just helping reading code structure. For some reason we are still stuck with a tree of files besides some glorified text editor.

Interestingly, we have made incredible progress into code comprehension. We have incredibly mature ast parsers, lsp servers, … our IDEs know everything about our code structure but we still fail to make anything else with that data than autocompletion and doc popups.


It’s called “sticky scroll” in VSCode and Visual Studio [1]. It pins the opening line of a scope to the top when it scrolls out of view and it does it multiple levels deep so you can see the class, function definition, conditionals, etc at the top of the source file when browsing deeply nested code.

[1] https://learn.microsoft.com/en-us/visualstudio/ide/editor-st...


Okay that’s cool :)


There is some great work being done here - I'm watching GToolkit advances, and while I don't fully buy the "moldable" hype, the UX of reading and writing code in GT feels like sci-fi sometimes.


So, this is a problem with using good editors. I don't know if VSCode or any similar editors have the way to select current block / current function, but in Emacs (and mostly likely Vi(m)) world this is just part of knowing the ropes. So, giving extra emphasis to the end of the function (or block) is completely unnecessary, it just reduces entropy.

Other problems with this: one of the ways to navigate the code is by searching for the function (procedure) name. Now you have double the number of matches.

Also, when I find code with comments that add labels like "end of xxx", I automatically delete all of these. It doesn't help me at all, and only makes searches in the code more difficult. Even the bad editors like VSCode probably have the functionality to jump to matching delimiter, which would easily reveal the name of the block you are working with.

And your company guidelines... oh, it should be fun when someone renames a namespace, but forgets to update the comments. At least, in Ada it's guaranteed that the end and the beginning will match. Also, sometimes I prefer not to invoke any kind of automatic refactoring, but rather rename a function and see what other code breaks, to quickly find dependencies. It's really annoying that this renaming must happen twice.


If you can't see the other end of a curly brace inside a function, I'm pretty tempted to say you're doing too much in one spot.


Extracting sequences of statements into a function sometimes improves readability, when those sequences do together some recognizable operation, but other times such an extraction worsens a lot the readability, because now you need to also open other pages to see what the program really does, when the statements in a sequence are not really related.

Even in programs optimally written for readability it is frequent to have iterations or selection statements much bigger than a page, especially where the coding rules enforce a small length for program lines, e.g. 80 characters.

In languages that follow Algol 60, like Pascal, C, C++ and so on, which have a single kind of statement brackets, it is frequently needed to add comments on the final braces or "end", to avoid confusions when reading the program.

This is much more cumbersome than in the languages that follow Algol 68, e.g. Ada and bash, where there are several distinct pairs of statement brackets.


I do occasionally have a long switch statement that doesn't lend itself to be broken up. If all the branches are simple and operate on the same conceptual level, breaking them out into separate functions that wouldn't be useful anywhere else doesn't make sense to me.

But it's definitely not a frequent enough occurrance to merit replacing closing braces with lengthy names that need to be kept in sync with their opening counterpart.


In real life you’ll have to deal mostly with code you haven’t wrote yourself.


Agreed but it’s not always my own code I am reading.


Pretty sure Java in vscode and android studio places block names after }'s because it's hard to read otherwise.


End names are optional in Ada, so "fixing" that is just a style guide away. Meanwhile, Scala 3 added named `end` to help with long blocks on its indentation syntax.


Like in all such discussions: the problem isn't with what you write, but with what you read. There are tons of Ada code that's already written like that. So, future changes to the style guide aren't going to do much. Also, nobody's changing that anyways.


I got used to it after writing a lot of complex SQL. I even developed a preference for uppercase keywords.


Philosophically this is a fair point but practically it is not. Eventually any programmer will start relying more and more on tools to help with skim/read/comprehend code bases, no matter the language. There's a reason that every text editor and IDE used for programming includes helpers to find subroutine calls, jump to matching symbol (curly braces, closing parenthesis, end statement, or tab-depth indicator), etc, etc. No language is so "easy to skim/read and comprehend" that you'd be happy with a realistically significant code base and only the navigation keys on your keyboard.

There's a very fine line between nice language syntax and ease of use via tools you use to interact with the language (with APL-influenced languages being the only exception I can think of, but even there I've heard of programmers having physical key map symbols overlaid on keyboards).


It was considered verbose years ago but now days it is IMHO better than messy C++ templates or Rust syntax.


I really wanted to use Ada, at least learn it. Concepts are nice but I gave up when started looking into unicode support. It was wild, a bit discouraging. Or has the situation changed? What’s the unicode status in Ada?


You can embed and work with UTF-8 strings with no issue (I have source with emoji string literals), but if you need complex manipulation of code points vs glyphs etc. I’m not sure how robust the libraries are for what you are trying to do.

https://ada-lang.io/docs/learn/how-tos/gnat_and_utf_8/


Thank you, this is very useful information.


The grumbling about the Azov Battalion and martial law in Ukraine is deflection. Pretty much every nation has some amount of paramilitary nationalism, and it should surprise nobody that a country at total war is going to suspend civil liberties. The war in Ukraine has basically nothing to do with fascism and everything to do with Russian revanchism that NATO would never allow to go unopposed, and it's pretty clear what's in the best interest of Western Europe and the US in this situation. Letting a perennial bad actor walk all over you because there's a veneer of largely irrelevant historical legitimacy over what is pretty clearly a test to see what you'll let slide is just stupid.


"The justice system should not be retributive" is a poor way to phrase it. I think what OP intended to say is that at least on paper, it is at about the right level of retribution right now, and that increasing it really isn't helpful.

In the American justice system, you do the crime and then do the time, after which you are released and can live as a free man for the rest of your days. If the crime is especially unforgivable, you go in for life. There is a major disconnect in people's understanding of that. People disagree with the sentencing, but then fixate on the idea that somebody might be able to live a normal, pro-social life upon release and focus their anger on that instead of what they actually have an issue with.

"Protect your perpetrator" is a really huge stretch. Letting someone who is in for 5-10 years for pushing crack get a job they can work from their cell so they can potentially get right upon release is definitely preferable to ensuring the perpetrator turns into a career fuckup.


> Letting someone who is in for 5-10 years for pushing crack get a job they can work from their cell so they can potentially get right upon release is definitely preferable to ensuring the perpetrator turns into a career fuckup.

Yes, but some crimes hurt specific people, badly. Some victims seek a measure of retribution, and in a different place and time we all could agree that is "justice". Some other legal systems extricate themselves from this conflict by placing perpetrators at the mercy of their victims. The US system is not superior in its efforts to withhold from victims the satisfaction of appropriate retribution. In exactly the same way you think 5-10 years in the scenario above is unjust, I think a system that ignores the impact of crime on victims is worse than useless.


The 5-10 years isn't unjust. Even them fucking up afterwards and going back in isn't necessarily unjust. It's just that recidivism in that case is an avoidable thing, but people would just let it happen because they can imagine some situation where some perpetrator deserves worse. It's frankly an incredibly stupid hill to die on, even if you completely discount the wellbeing of the person being incarcerated.

The system isn't ignoring the impact of crime on victims, it just doesn't let victims completely run the show in sentencing/punishment. Sometimes there's bad outcomes, but that's fixable. You can never fix people that feel the death sentence is appropriate for even the slightest transgression, and if you add some sort of oversight to that you're right back where we are.

You do not want street justice. I don't understand how one could possibly not understand how bad it would be. There's a reason we rag on societies that enable it.


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: