Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Giving Ada a Chance

ajxs.me

Post reply on HN
Print view View original

241–250 of 261 posts

Re: Giving Ada a Chance

#241

Post by Lucretia9 »

claudionaoto wrote: post #164
p_l wrote: post #145

Earlier quoted context omitted.

Wirthian languages seemed to keep the 6bit symbol encoding of the original Pascal, where the symbols and keywords ended up case-nonpreserving. Was that changed at any point with Modula or Oberon? I never have seen any code with all caps.

Oberon is case-sensitive and all keywords are all caps. I was curious to see it because I like Object Pascal/Delphi, that was the most distracting part of the language coming from Delphi standards.

> Oberon is case-sensitive and all keywords are all caps. I was curious to see it because I like Object Pascal/Delphi, that was the most distracting part of the language coming from Delphi standards.

Yeah, it's horrible to see and worse to type. I took Oberon-2's grammar and changed it to a more Ada like one for a project I'm working on.

Re: Giving Ada a Chance

#242

Post by Lucretia9 »

foerbert wrote: post #141
Lucretia9 wrote: post #118

Earlier quoted context omitted.

Yeah, ranges and modular types for me, without them data modelling is hindered severely.

Ranges are a pretty big part of it for me, but what really gets me is the ease of creating useful new types. Having to destructure a new type to use it, or create a bunch of pass-through functions kinda ruins the point. I haven't seen any language really have a strong cultural focus on types like Ada does, and I think the ease of creating and using new types is the cause. I think the best I've actually seen in this r…

Most languages just go with machine size "types" and no strict typing on those. I've not seen any other languages do what Ada does. I've got my project to do so though.

Re: Giving Ada a Chance

#243

Post by Lucretia9 »

zdragnar wrote: post #35
eplanit wrote: post #22

A nitpick, but why is Ada in all caps in the title? It isn't in the article, nor is the name an acronym.

Probably an autocorrect; the language is less commonly used than the Americans with disabilities act.

It should autocorrect as the female name Ada, my phone does.

Re: Giving Ada a Chance

#244

Post by bee_rider »

fulafel wrote: post #195
bee_rider wrote: post #65

Earlier quoted context omitted.

I help beginner python students. Python might be a nice easy scripting language for bashing out NUMPY scripts, but I'm beginning to suspect it is terrible for teaching. The "what type is this variable, and will this function automatically convert it for me" game is not very fun at all for beginners.

Beginners to programming don't agonize over variable types, they don't have the mental model of statically typed language in their head.

They might not "agonize over variable types," but they do encounter agony when they try to add a string to an integer.

Re: Giving Ada a Chance

#245

Post by OneWingedShark »

pkolaczk wrote: post #231
7thaccount wrote: post #227

Earlier quoted context omitted.

That study is also based off of Rosetta code tasks. I'm not sure if that accurately portrays code in the wild. Java codebases are full of design patterns that are entirely uneccessary in Python. Ever hear someone talk about design patterns for Python? It exists, but it is niche instead of the norm and I've literally never heard it mentioned in hundreds of hours talking about Python with coworkers. I'm sure Rust makes…

Is Python not an OOP language? I think it is, so OOP design patterns still apply to it. So the differences you observed might be not because of a language itself, but the complexity of projects these languages are applied to and cultural differences of the teams. So far I haven't worked on Python projects as big (in terms of functionality) as Java projects I've seen. As for data science, so far I haven't stumbled upo…

> As for concurrency - gluing systems together sometimes needs concurrency to cut the latency down. And in data science parallelism also means performance, and often it is needed. I'm not that convinced Python is a clear winner here.

Ada is really quite good here, the Task is something such that I would say that if your application is inherently going to be dealing with concurrent processes you should seriously consider Ada. -- The 2020 standard is adding a Parallel keyword/block so that it should be (in theory) as easy to use e.g. CUDA parallelization as simply as compiling your code with a CUDA-aware compiler.

Re: Giving Ada a Chance

#246

Post by OneWingedShark »

the_only_law wrote: post #125
Lucretia9 wrote: post #112

Earlier quoted context omitted.

>I love Ada, unfortunately it’s real world use seems to be relegated to old legacy code. I’d like to use it a little more on the side, but I also need to keep my priorities focused on realism, which sadly means ignoring Ada and learning something like C++ which seems unapproachable from any angle. Oh, my github must be ancient then! > Ada also seems to have a weirdly negative rep in many circles it seems. I recall lo…

Heh, I must say way, impressive GitHub. You the original author of the OSDev wiki’s barebones Ada tutorial? Off topic, but have you ever heard of CHILL? It’s a language from the ITU designed for telephone switches (like Erlang) but is supposedly very similar to older Ada standards.

I have heard of it, and was tempted to grab a copy of the spec. -- The context in which I heard it, language design, Ada was put forth as the only language designed for both maintainability and correctness, someone responded that CHILL was another, but the only other they knew of.

https://psc.informatik.uni-jena.de/publ/1999-T-REC-Z.200-199...

https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Z.20...

Re: Giving Ada a Chance

#247

Post by kibwen »

OneWingedShark wrote: post #237
kibwen wrote: post #190

Earlier quoted context omitted.

> "As of Rust 2018, this still can cause undefined behavior." This is referring to the fact that you have to be careful when accessing the fields of a packed struct that everything is aligned correctly. Normally anything where "you have to be careful" in order to uphold memory safety requires use of the `unsafe` keyword, but due to an oversight Rust doesn't currently require it in this instance. So, in typical Rust f…

>> "As of Rust 2018, this still can cause undefined behavior." > > This is referring to the fact that you have to be careful when accessing the fields of a packed struct that everything is aligned correctly. Normally anything where "you have to be careful" in order to uphold memory safety requires use of the `unsafe` keyword, but due to an oversight Rust doesn't currently require it in this instance. No, there's a hu…

Rust uses "unsafe" to refer specifically to memory safety, not merely for any operation considered generally undesirable. Because UB can cause any effect at all, anything that is potentially UB is regarded as "unsafe".

Re: Giving Ada a Chance

#248

Post by kibwen »

souprock wrote: post #233
kibwen wrote: post #228

Earlier quoted context omitted.

Misbehavior manifests even on x86, see the tracking https://github.com/rust-lang/rust/issues/27060 for examples. If you have more information, please leave a comment there.

Somebody already made a comment, which seems to be getting ignored: https://github.com/rust-lang/rust/issues/27060#issuecomment-... Basically, Intel goofed back when SSE was first introduced, and some compilers (including both gcc and llvm) got tripped up. Intel made two instructions for loading SSE registers, a normal one and one that would take alignment faults. There was the suggestion that the one with alignment…

I don't believe they're being ignored, however, I encourage you to comment if you have something to add, even if it is just to reiterate that comment in a modern context.

Re: Giving Ada a Chance

#249

Post by icedchai »

OneWingedShark wrote: post #235
icedchai wrote: post #152

Earlier quoted context omitted.

How can you say C has no real value in a professional setting? Look at the amount of C code in any Linux distribution, even ignoring the kernel itself.

> How can you say C has no real value in a professional setting? Fairly easily. My professional career has been mainly in maintenance and, as such, I get to see the gritty back-end of things, the end-result of all the technical-debt... and being more correctness and security-minded than most, I often note how a good design could help prevent problems, both on the language being used to implement and on the project it…

I think you and I see "value" differently. C is literally everywhere. Other people know it and are able to work with it. Tons of existing code is written in C. Most other languages can interface with it. This combination makes it incredibly valuable in a professional setting.

It is used inappropriately? Sometimes. Can there be better alternatives? Yes. But to say it has "no real value" is a bit extreme.

Re: Giving Ada a Chance

#250

Post by Lucretia9 »

OneWingedShark wrote: post #246
the_only_law wrote: post #125

Earlier quoted context omitted.

Heh, I must say way, impressive GitHub. You the original author of the OSDev wiki’s barebones Ada tutorial? Off topic, but have you ever heard of CHILL? It’s a language from the ITU designed for telephone switches (like Erlang) but is supposedly very similar to older Ada standards.

I have heard of it, and was tempted to grab a copy of the spec. -- The context in which I heard it, language design, Ada was put forth as the only language designed for both maintainability and correctness, someone responded that CHILL was another, but the only other they knew of. https://psc.informatik.uni-jena.de/publ/1999-T-REC-Z.200-199... https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Z.20...

Both those links are the same, btw.

I can see why it's no longer used, with all those modes! But another language with ranges. Also has module inheritance.

Post reply on HN