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

181–190 of 261 posts

Re: Giving Ada a Chance

#181

Post by 7thaccount »

iamevn wrote: post #39

> I can’t help but think that complicated programming paradigms would seem more intuitive to beginners if taught through Ada instead of C and its derivative languages, as is common in computer science and engineering faculties worldwide. At my university, the first courses you took in CS used Ada. I think it was a really good choice but I was in the minority I guess because after my year they switched to either using…

There's a lot of Python dislike on here, so I thought I'd add my anecdotal story.

I learned Basic, C, Assembly, and Matlab in college (in that order). However, I was never a very good programmer. After graduating, I bought an intro to Python book and read it cover to cover and did the examples. I then started writing scripts and it all kind of clicked. I found it really simple to build stuff. There's lists, tuples, dictionaries, functions, iterating, easy branching...etc. There wasn't a whole lot to remember. I did find it confusing at first why some things used function syntax min(a) and other things used object oriented notation like mylist.sort(), but it wasn't too hard to remember all the stuff I actually needed. I was able to start using classes when I felt I was ready.

Since then I've read books on and played around with Clojure, Common Lisp, Haskell, APL, Forth, Prolog, Ada, Powershell, Perl, Bash, Awk, Julia, C#, SQL...etc. During that time, I've found that Python holds it's ground in being very expressive, while easy for others to understand and performant enough for most uses with libraries like Numpy. Each time I try to move to a "grown-up" language like Java, I'm shocked at how verbose and clunky everything is. Sure it's great for production systems, but it's awful at just getting stuff done.

Python is used almost exclusively by all engineers at my company (some C#) in hundreds of automation scripts. Some programs are 10,000+ lines of code and are still maintained and easily read by others. We're mostly electrical engineers too, so everyone picked up coding on their own and we find most codebases are still pretty consistent.

I think Ada is a neat language for high reliability systems, but I don't think I'd choose it as a teaching language due to a lot of the friction with getting simple programs to work and wrestling with types. I've had very few issues with types in Python. I generally just use string, int, and float conversions when needed.

Re: Giving Ada a Chance

#182

Post by rsj_hn »

goatlover wrote: post #159
Blikkentrekker wrote: post #151

Earlier quoted context omitted.

I feel that Python will be known in the future as the language that caused a generation to have a crippled sense of reasoning about how to design computer programs. It's lack of a normal, standard scoping model alone teaches a very flawed reasoning about computer programs.

I'd vote for Javascript over Python.

Javascript is too weird to be a teaching language. Lexical scoping, invisible and sometimes unintuitive conversion rules, challenging runtime environments, and asynchronous code are important concepts but I wouldn't put them into an intro to programming class.

IMO the ideal programming track would be as follows:

Intro to programming track:

* Assembly --> to understand the basics of how computers work and learn simple procedural and abstraction rules.

* C --> more procedural code, more abstractions, and higher order memory management

* Java --> to learn interfaces, object oriented code, and an introduction to functional programming concepts like lambdas, pure functions, the value of immutable objects

* {Racket/LISP or Favorite functional language} --> to gain intuition with more pure functional programming

Then, I'd have separate tools track:

* web dev

* database

* embedded dev

* AI, etc.

Then a separate theory track:

* context free languages, regular expressions, compiler design

* algorithms and data structures

* some network theory and fault tolerance results

Then I'd have a professional track:

* tools: learn source control systems, IDEs, debuggers, profilers, bug management systems, different dev systems, using Jenkins or other CIT tools.

* skills: learn about secure coding (best practices for writing auditable code with known failure modes), efficient coding (calculating big O for a given code, fixing performance bottlenecks), maintainable coding (best practices for decoupling code, writing testable code, writing unit tests)

* theory: track where you learn advanced algorithm theory, design patterns, hopefully centered around case studies.

With elective tracks for things like OS theory, networking, etc.

Too many people leave college with lots of information about data structures and algorithms but don't know how to write a unit test, how to use an IDE, how to write unit tests, how to write secure, maintainable code.

Re: Giving Ada a Chance

#183

Post by bb88 »

Blikkentrekker wrote: post #179
bb88 wrote: post #176

Earlier quoted context omitted.

How about not using lambdas which create accidental closures all over and use partial functions, instead? list.append(functools.partial(some_code_that_closes_over, x)) If you replace a lambda with a function definition in the for loop, it's easier to see the scoping issue is actually a closure. And that makes sense because lambda is shorthand for a function.

Because the code that closes over can be arbitrarily complicated. I simply used code that only called a function with a single argument as a minimal example. Apart from that, your code technically does not do the same thing as it calls the inner function with two arguments, whereas mine simply discards the second argument.

But your argument is about scoping. Replacing the lambda with a function inside the for loop shows the closure plainly. So your complaint can't be about scoping, or maybe this is a bad example of your argument.

Maybe your complaint is about the fact that statements inside a lambda isn't called until the lambda is called. But again, lambda's are just functions, and closures are closures.

Or maybe your argument is that closures are easy to make in python, which is true. But that doesn't mean the language is bad, since lots of languages use closures.

Re: Giving Ada a Chance

#184

Post by Blikkentrekker »

bb88 wrote: post #183
Blikkentrekker wrote: post #179

Earlier quoted context omitted.

Because the code that closes over can be arbitrarily complicated. I simply used code that only called a function with a single argument as a minimal example. Apart from that, your code technically does not do the same thing as it calls the inner function with two arguments, whereas mine simply discards the second argument.

But your argument is about scoping. Replacing the lambda with a function inside the for loop shows the closure plainly. So your complaint can't be about scoping, or maybe this is a bad example of your argument. Maybe your complaint is about the fact that statements inside a lambda isn't called until the lambda is called. But again, lambda's are just functions, and closures are closures. Or maybe your argument is that…

No, my complaint is, as said, hat for-loops in Python do not create a block scope as they do in about any other language. The closure is simply a way to illustrate that but there are many other problems such as this one:

  x = something
  # some lines of code
  for x in iterator:
    # something
  # try to use x again here
  # x has been re-assigned by the loop
In about any other language, the loop would create it's own scope, and thus shadow the existence of the outer `x`, rather than re-assigning it.

Re: Giving Ada a Chance

#185

Post by adrianN »

rsj_hn wrote: post #182
goatlover wrote: post #159

Earlier quoted context omitted.

I'd vote for Javascript over Python.

Javascript is too weird to be a teaching language. Lexical scoping, invisible and sometimes unintuitive conversion rules, challenging runtime environments, and asynchronous code are important concepts but I wouldn't put them into an intro to programming class. IMO the ideal programming track would be as follows: Intro to programming track: * Assembly --> to understand the basics of how computers work and learn simple…

I really don't think you should use C as a teaching language. There are way too many pitfalls, and using libraries is quite cumbersome.

Re: Giving Ada a Chance

#186

Post by kqr »

Blikkentrekker wrote: post #171
nerdponx wrote: post #165

Earlier quoted context omitted.

It's lack of a normal, standard scoping model alone teaches a very flawed reasoning about computer programs. Scoping in class definitions is weird, yes. But is that your complaint? What's wrong with the scoping model in general?

It's not merely that. That for-loops work by assignment rather than creating a new scope, or that if-conditions do not create a new scope for their arms is most unusual. Not only does it not teach programmers to properly reason about scope, but it results into subtle bugs that are easy to miss. Consider the following: list = [] for x in iterator: list.append(lambda y: some_code_that_closes_over(x)) This almost certai…

Not a technical counter argument, but surely this is a trifle in the grander scheme of things? The hard things about programming, such as modularization at a high level and verification of user input, are orders of magnitude more important than quirks like these?

(And if we broaden our view to include more of software engineering in general, like solving the right problems and validating hypotheses with fast feedback, it seems even more insignificant.)

Re: Giving Ada a Chance

#187

Post by [deleted] »

rsj_hn wrote: post #182
goatlover wrote: post #159

Earlier quoted context omitted.

I'd vote for Javascript over Python.

Javascript is too weird to be a teaching language. Lexical scoping, invisible and sometimes unintuitive conversion rules, challenging runtime environments, and asynchronous code are important concepts but I wouldn't put them into an intro to programming class. IMO the ideal programming track would be as follows: Intro to programming track: * Assembly --> to understand the basics of how computers work and learn simple…

[deleted]

Re: Giving Ada a Chance

#188

Post by bb88 »

Blikkentrekker wrote: post #184
bb88 wrote: post #183

Earlier quoted context omitted.

But your argument is about scoping. Replacing the lambda with a function inside the for loop shows the closure plainly. So your complaint can't be about scoping, or maybe this is a bad example of your argument. Maybe your complaint is about the fact that statements inside a lambda isn't called until the lambda is called. But again, lambda's are just functions, and closures are closures. Or maybe your argument is that…

No, my complaint is, as said, hat for-loops in Python do not create a block scope as they do in about any other language. The closure is simply a way to illustrate that but there are many other problems such as this one: x = something # some lines of code for x in iterator: # something # try to use x again here # x has been re-assigned by the loop In about any other language, the loop would create it's own scope, and…

So your first example was clearly a bad example. This was a better example.

But even so, this is a lousy example since x is already defined at the top. So the for loop could theoretically use the defined x already.

I think what you're looking for is something akin to the following in C:

    int x = 5;
    for (int x=0; x
But I would argue that this is terrible C code since the inner x shadows the outer scope leading to confusion as to which x the loop is iterating on. But you could also write the for loop like this:

    for (x
So C doesn't dictate the scope of the loop which could be argued by your standards, even more confusing than python. Python just says your scope is just function level. Subtle C code changes can create scoping bugs.

So even the scoping example your trying to use is fraught with issues for new developers. Is "function-level" scoping better than "C-style" scoping say? I tend to think that function level scoping forces developers to simplify their code as it discourages symbolic shadows.

Re: Giving Ada a Chance

#189

Post by lmm »

kqr wrote: post #186
Blikkentrekker wrote: post #171

Earlier quoted context omitted.

It's not merely that. That for-loops work by assignment rather than creating a new scope, or that if-conditions do not create a new scope for their arms is most unusual. Not only does it not teach programmers to properly reason about scope, but it results into subtle bugs that are easy to miss. Consider the following: list = [] for x in iterator: list.append(lambda y: some_code_that_closes_over(x)) This almost certai…

Not a technical counter argument, but surely this is a trifle in the grander scheme of things? The hard things about programming, such as modularization at a high level and verification of user input, are orders of magnitude more important than quirks like these? (And if we broaden our view to include more of software engineering in general, like solving the right problems and validating hypotheses with fast feedback…

Poor syntax or surface-level semantics make a language exponentially harder to use, because every layer of your program becomes more difficult. You have to make your modules smaller which means you have to split them up more and have more interfaces between them. Etc.

Re: Giving Ada a Chance

#190

Post by kibwen »

ajxs wrote: post #156
kibwen wrote: post #34

In answer to what appears to be a misunderstanding about Rust: > Its foreign function interface seems particularly poorly implemented. The official Rust documentation suggests the use of the external third-party libc library (called a 'crate' in Rust parlance) to provide the type definitions necessary to interface with C programs. As of the time of writing, this crate has had 95 releases. Contrast this with Ada’s Int…

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 fashion, this isn't referring to anything sinister like a compiler miscompilation, it's just an error that Rust isn't being as paranoid as it strives to be. :P

The patch to require this `unsafe` annotation was actually just filed last week; it will become a warning first, then might become a hard error for users who opt-in to the upcoming 2021 edition: https://github.com/rust-lang/rust/pull/82525

Post reply on HN