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

231–240 of 261 posts

Re: Giving Ada a Chance

#231

Post by pkolaczk »

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

Earlier quoted context omitted.

Not sure what boilerplate in Rust or Scala you're talking about. I admit Rust is much harder to learn initially, but once learned properly, the amount of code in both languages is very similar (as long as we're not comparing one program calling out to a library and another one doing everything from scratch). Both can be very high level. Here is a study where they've found Python to be not much less verbose than Java…

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 upon any Python code that wouldn't look very similar translated to Java, Scala, R or Rust, assuming same libraries existed. Most of the code is very simple really: load data into some vector/matrix, apply some library code on it, get a different vector/matrix back, etc. The only thing that holds me to Python really are libraries.

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.

Re: Giving Ada a Chance

#232

Post by dragonwriter »

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…

> Is Python not an OOP language? I think it is, so OOP design patterns still apply to it.

“Design Patterns” in software (particularly when talking about what you see in code) are used largely to refer to things that are not just design patterns, but a combination of design pattern plus workaround for limitations in the facilities for reusable abstraction in the target language that prevent implementing the design pattern via reusable abstraction.

In that use, there aren't really “OOP design patterns”.

Re: Giving Ada a Chance

#233

Post by souprock »

kibwen wrote: post #228
souprock wrote: post #196

Earlier quoted context omitted.

That is a mistake. Architectures are being updated to support unaligned access. MIPS, PowerPC, and ARM have all been updated. The machines that can't handle unaligned access are going the way of machines with sign-magnitude integers, trap representations, 9-bit bytes, base-16 floating-point, and so many other terrible things that must have seemed like good ideas at the time.

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 faults would perform better, so people used it. In later processors, the tiny difference went away. So now you have a useless instruction supported by the hardware, and it is getting emitted by LLVM.

All the other instructions that could be emitted by llvm, and all the instructions that should be emitted by llvm, do not take alignment faults.

Re: Giving Ada a Chance

#234

Post by pkolaczk »

dragonwriter wrote: post #232
pkolaczk wrote: post #231

Earlier quoted context omitted.

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…

> Is Python not an OOP language? I think it is, so OOP design patterns still apply to it. “Design Patterns” in software (particularly when talking about what you see in code) are used largely to refer to things that are not just design patterns, but a combination of design pattern plus workaround for limitations in the facilities for reusable abstraction in the target language that prevent implementing the design pat…

Fair point. So what are these limitations in facilities of abstraction that Python doesn't have and Java has?

Re: Giving Ada a Chance

#235

Post by OneWingedShark »

icedchai wrote: post #152
OneWingedShark wrote: post #117

Earlier quoted context omitted.

>I get what you're saying, but learning C teaches you about the C memory model instead of "real machines". No. C doesn't do that, not at all; see: https://queue.acm.org/detail.cfm?id=3212479 If you want to get to the down and dirty, and quickly, without nearly all the "Gotcha!" inherit in C, FORTH is the way to go. >C was designed for portability across different architectures Absolute bullshit. This is a claim that…

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 itself.

From that perspective, most defenses of C as productive or useful fall flat on their faces, especially in recent years as security becomes more and more important a concern — about the only place that C makes any sense anymore is micro-controllers because "all the micro-controllers have a C compiler." — But let's not make the mistake thinking that "having a C compiler" means that C is a good (or even appropriate) language for the task.

Forth, Assembly, and Ada all exceed C's capabilities in many of what have been traditionally claimed as C's strong suits: * Ada: much, MUCH, better as a systems-language. Any project of medium or large size should seriously consider Ada instead of C. * Assembly: very fine control, especially important for the severely-constrained controllers. * Forth: Very fast, very low-level; would recommend for small/medium-small projects on small controllers. (Doesn't have calling-conventions, doesn't manipulate stack-frames; this makes it faster than C.)

> Look at the amount of C code in any Linux distribution, even ignoring the kernel itself.

And? That says NOTHING about having value in a professional setting, only that it (a) was chosen by a project that got big, and (b) enjoys popularity.

Nearly EVERYTHING that C is claimed to be [very] good about is done much better by some other language. C is particularly bad at large-systems, given the complete lack of modules, and entirely unsuitable for many things that it's commonly used for like multithreaded applications (honestly, take a look at Ada's TASK construct and consider how that might be used in [e.g.] a game-engine).

Re: Giving Ada a Chance

#236

Post by Blikkentrekker »

mkl wrote: post #216
Blikkentrekker wrote: post #213

Earlier quoted context omitted.

> All you need is "x=x" to make a copy: Your code is illegal Python on two levels. - Lambdas in Python do not allow assignment at all. - Variables in Python cannot be assigned using themselves in their r.h.s., without first being assigned something else, because Python's scoping is strange. You serve well as an example of a programmer that does not understand Python 's semantics here, because they are very counter-in…

Maybe you should try running it before jumping straight to insults? My code is perfectly legal in Python and runs exactly as I said. Yours: In [1]: list = [] ...: for x in range(5): ...: list.append(lambda y: y+x) ...: [f(100) for f in list] Out[1]: [104, 104, 104, 104, 104] Mine: In [2]: list = [] ...: for x in range(5): ...: list.append(lambda y, x=x: y+x) ...: [f(100) for f in list] Out[2]: [100, 101, 102, 103, 10…

Ah yes, mea culpa, I misread your example as

  lambda x: x = x; do_thing(x)
Rather than the:

  lambda x, x = x: do_thing(x)
And yes, your example works, and is functionally similar to my initial solution of using that function scope does exist by simply creating a function for no other reason than to call it to create a new scope.

That doesn't stop that both examples are ugly hacks needed to solve a problem with the language that most languages do not have. And despite your calling it idiomatic, I have never seen your example in the wild and it is, frankly, simply a hack that few programmers that haven't been explicitly taught this trick would quickly see the intend behind.

Re: Giving Ada a Chance

#237

Post by OneWingedShark »

kibwen wrote: post #190
ajxs wrote: post #156

Earlier quoted context omitted.

Regarding `repr(packed)`: Thank you for posting this. I really like Rust's official documentation on the subject. I stand corrected regarding Rust's support of structure packing. The following statement is a little troubling however: "As of Rust 2018, this still can cause undefined behavior." This greatly affects Rust's suitability for bare-metal programming, where you very often require control over a structure's la…

> "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 huge difference between UNDEFINED BEHAVIOR and UNSAFE BEHAVIOR (in the sense of "be careful here").

Take Ada's "Unchecked_Conversion" function, it operates essentially the same as C++'s bitwise-cast, and thus is unsafe ("be careful" sense) but is not undefined.

Re: Giving Ada a Chance

#238

Post by SeanLuke »

fulafel wrote: post #197
SeanLuke wrote: post #135

Earlier quoted context omitted.

Do you have any evidence for this? As an early university adopter, I sure would have liked to know how to get in on that sweet Java bribe money.

In universities there were steep educational discounts of Sun hardware. At the time administering labs full of PCs was a nightmare, and a lot of departments were culturally predisposed towards Unix anyway, so a natural result in many places was Sun workstations or Sun Ray terminals where Java was well supported and was portable enough to also run on the student personal PC. This is a well known pattern in services no…

In 1996-1997 I ran Java 1.0 or 1.1 on Solaris, MacOS 9, and Windows. I developed for, and on, all three. It was available on a number of other Unix implementations, including Linux and DEC. In addition to HotJava, Java applets ran on Netscape. In 1997 Symmantec had a popular free JIT that ran on most everything. These platforms dwarfed Solaris installations. How exactly were these minor Solaris boxes helping sell Java again?

Quite to the contrary. If anything, Java was helping sales of future Sun boxes, rather than the other way around. Sun worked hard to make sure Solaris ran Java efficiently and stably, so if you were a Java developer you might consider Sun boxen professionally.

Re: Giving Ada a Chance

#239

Post by Lucretia9 »

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.

> Heh, I must say way, impressive GitHub. You the original author of the OSDev wiki’s barebones Ada tutorial?

Thanks. Yes, you can tell because it doesn't show as a fork on my gh and it should show on the wiki who wrote it.

> 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.

Yeah, heard of it, that is all though.

Post reply on HN