Hacker News Reader

Comment by iamevn | Hacker News Reader

> 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 Java or Python depending on who taught which of the courses in that first series.

People found it frustrating how much work it'd take to get their programs to even compile but that's a good thing in my view. If it wasn't compiling, that was normally because the compiler found an error that would still be there at runtime in another language.

View on HN

> People found it frustrating how much work it'd take to get their programs to even compile

Makes sense if they're students working on small projects. Ada is explicitly designed to make large programs readable, and willingly trades off on writeability when the two come into conflict. It isn't going to shine if you're writing small 'single shot' applications, that isn't what Ada is for.

(Ada also commits to using many English language words where languages like C use symbols. SQL does this too. I'm not sold on the idea that this improves readability. Of course, there's far more to Ada than the skin-deep matter of its wordy syntax.)

This is similar to the readability/writeability tradeoff of moving from JavaScript (more writeable) to TypeScript (more readable and more refactorable). See the current discussion thread at [0].

Interesting reading (for some of us at least): the original Ada design rationale document, from 1986 [1].

[0] https://news.ycombinator.com/item?id=26314756

[1] https://apps.dtic.mil/dtic/tr/fulltext/u2/a187106.pdf

> (Ada also commits to using many English language words where languages like C use symbols. SQL does this too. I'm not sold on the idea that this improves readability. Of course, there's far more to Ada than the skin-deep matter of its wordy syntax.)

Wasn't the hypothesis behind COBOL that this would allow managers to gain a certain level of understanding of the code?

I find that it made COBOL code notoriously unreadable.

C is actually middle ground, if you consider APL.

I really think a semantic facelift would do wonders for ADA, and shouldn't make much of a difference for readability. I know a lot of people are turned off by this.

> I really think a semantic facelift would

I think you mean a syntactic facelift, without changing semantics. You mean making the syntax look more like TypeScript, Kotlin, or something, right?

Yes! Thanks for the correction!

I suspect overhauling the syntax is the kind of change that the committee would see as rather dramatic and with limited payoff. Introducing an optional alternative syntax alongside the existing one, would likely be seen as opening the door to syntactic inconsistencies, more likely to harm readability than to enhance it. The Python community has a relevant saying: There should be one -- and preferably only one -- obvious way to do it. [0]

I don't think it's a serious problem that Ada uses and then rather than &&, and uses or else rather than ||. It's the kind of thing you can get used to with time.

[0] https://www.python.org/dev/peps/pep-0020/

and then and or then are shortcut operations, not the same as && and ||, those are and and or.

In C and C++, the && and || operators both short-circuit. For eager semantics in C/C++ you could make do with the bitwise operators & and |, keeping in mind that they're bitwise and not logical. You could do something like (!!first_int) | (!!second_int). You'd be better off forcing eager evaluation by saving the results to local variables, and then use the short-circuit logical operators.

Ada's and and or operators have no direct equivalents in C or C++.

https://en.wikipedia.org/wiki/Short-circuit_evaluation#Suppo...

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.

I agree that Python is a bad language for beginners. It is conceptually heavyweight and full of opaque behavior. We lost a lot when BASIC stopped being the "standard" introduction to programming.

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 not so often used as a teaching language.

There are many languages which hammer worse practices than either such as POSIX shell scripts, but they are seldom used as a teaching language.

Python is in the unique space of having made horrible design decisions but somehow often used as a teaching language.

One would assume that programmers are to understand such concepts as block scoping rules and the difference between lexical and dynamic variables. — how is Python to teach them that?

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.

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.

I wouldn't program production code in C if I could avoid it. But sometimes you can't avoid it, and I wouldn't program production code in Pascal, either.

A programming language can both be the best fit for a concrete production problem and very unsuited as a teaching language.

All of my academic computer science instruction was done in C. I was going to mention this in a response to one of the above comments regarding the pedagogical value of Python: I don't feel that taking onboard the concerns that come with programming in C (such as memory management) really made learning about computer science's fundamental algorithms and abstract data structures any easier. Many of the abstract data structures in question, such as trees and hash-maps, when practically implemented are dependent on an understanding of pointers that makes C an ideal pedagogical tool in at least one aspect.

I don't think it's really practical for every scenario. I still think it's a great tool for teaching students about many aspects of how a modern computer, or operating-system functions. You definitely won't get far in gaining a holistic understanding of any modern operating-system without understanding C.

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

Jesus Christ, Java as an introduction to functional programming? I don't even know what to say.

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 certainly does not behave as the programmer intended, for the for-loop does not create a new scope, so all iterations of the loop share the same scope, and thus every closure that closes over `x` handles the same `x`, which will have the value that `x` had at the last loop, thus effectively mutating the closure after appending it to the list, so that the list will only contain effectively identical closures.

The proper way do it is by using the fact that functions do create a scope:

  list = []
  def loop_function(x):
    list.append(lambda y: some_code_that_coses_over(x))
  for x in iterator:
    loop_function(x)

Certainly code that looks quite hackey to work around the lack of normal, expected block scoping.

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.

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.

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<10; x++) {
        int y = 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<0; x<10; 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.

No, the first example illustrates the fundamental problem that all iterations of the loop share the same scope rather than a new one each.

In your example, the variable `x` is also shared with all iterations of the loop. Rather, it is more so as so in C, like syntax what is the common approach:

  while(1) {
    int x = next(iterator)
    if(STOPITER) { break }
    /* code that uses x */
  }

Every iteration of the loop receives a brand new `x` rather than re-assigning the old `x`, this problem is illustrated by creating a closure that closes over the `x`, for which the expected behavior is not that the `x` is then assigned to another value on the next iteration of the loop.

The only way to achieve this in Python is to create an ad-hoc function which is passed `x` as a formal parameter, for every new function call in Python does create a new scope rather than simply re-assigning to the last one.

I would argue that code that is sensitive to scope is bad code no matter which language it's written in, since now you're constantly asking "When does a variable leave scope." If I change the scope of a variable, it causes a subtle change that breaks the closure.

In that case I would prefer to be explicit that the closure "wraps" a new instance of the variable rather than relying upon implicit language behavior to guarantee the scope is correct.

As python says in "import this": "Explicit is better than implicit."

> I would argue that code that is sensitive to scope is bad code no matter which language it's written in

Then you have argued that using any form of functions or subroutines in any language is bad design.

> since now you're constantly asking "When does a variable leave scope." If I change the scope of a variable, it causes a subtle change that breaks the closure.

Yes, that is what one must ask oneself as a programmer and that is what programmers who have not been taught wrong practices by having used Python as their introduction are instinctively constantly asking themselves.

Python programmers must also ask themselves this whenever they use functions and Python comes with a variety of ugly hacks around it's initial wanton design by a programmer who clearly does not understand scope how he originally designed it such as `nonlocal`.

Inside any function in Python there are four kinds of variables in terms of their scope: normal, formal, global, and nonlocal, each of them has a different scope and the programmer best be mindful of which is which as he codes, because they have widely different semantics and because Python has the same syntax for assignment and initialization and this difference especially creates very different interpretations for those four types.

> In that case I would prefer to be explicit that the closure "wraps" a new instance of the variable rather than relying upon implicit language behavior to guarantee the scope is correct.

I feel that you have a fundamental misunderstanding of what a closure or function is if you think it even possible for it to wrap a new instance of a variable.

You seem to be of the same misunderstanding as another user above that `let x = x;`-esque behavior would affect this issue in any way rather than be an irrelevant line.

> As python says in "import this": "Explicit is better than implicit."

Not only is this very rich coming from a language that uses exceptions for flow control, and the same syntax for initialization and assignment, it's also irrelevant and not a matter of explicitness versus implicitness.

Whether wrapping variables would be implicit or explicit in this context would not have solved the issue at all. Even if Python mandated explicit wrapping or made shadowing illegal, which some languages do, for which there is argument to be had, it would not change this subtle bug at all.

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

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.

But block scope is all about modularization and ensuring that parts of the program that need not interact do not interact.

Python code seems to either be written from a mentality of not at all caring about variable lifetime and making it far longer than it should be, or programmers that do care, and uses classes and functions as makeshift tools to attempt to limit the lifetime of variables to make up for the lack of block scope of the language.

All you need is "x=x" to make a copy:

  list = []
  for x in iterator:
    list.append(lambda y, x=x: some_code_that_closes_over(x))

That way the closure is explicit and much clearer when you look at it later.

("list" is a builtin, so not a good variable name.)

> 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-intuitive, and you also serve as an example of a programmer that does not understand how scope works at all, even if your example be worked into something of valid Python syntax:

  thunks = []
  for x in "abcd":
    def thunk():
      y = x
      print(y, end='')
    thunks.append(thunk)

  for thunk in thunks:
    thunk()

The output is `dddd`, not `abcd`; the `y = x` part is completely irrelevant in this case, for when the thunk is called, `x` has already been re-assigned, and so `y = x`, is assigned the new value.

Again, `x` is re-assigned on every new iteration of the loop, as such the `x` in every single one of those thunks contains the value `x` had at the last iteration of the loop when the loop completes.

There are many ways to solve this issue, such as the one I initially gave, but yours isn't one of them and that you thought it was shows the counter-intuitive nature of Python's behavior here.

> ("list" is a builtin, so not a good variable name.)

Which would be another problem with Python's lack of scope. Shadowing the names of library functions and constants is not problematic in languages with proper block scope.

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, 104]

I understand the semantics just fine, and it's very clear what's going on. In my version, each lambda has two parameters, one called y, and one called x. The one called x has a default value, and the default value is whatever the loop variable x's current value is: a copy is made of the loop variable's value, and stored as a default parameter value. There is no assignment, and a variable is not assigned to itself. The parameter has the same name, but the scope is different; within the lambda, the parameter shadows external variables, just as in any function.

This is idiomatic Python code, taught to beginners (search for n=n - it's about this same loop thing): https://realpython.com/python-lambda/

You do the same thing when passing parameters through to an inner function, like this:

  def outer(x, y):
    def inner(z, x=x):
      return z+x
    print(inner(2*y))

Shadowing list in a function scope is fine (just confusing), but your code does it in the global scope.

You seem to have a bone to pick with Python for some reason, but to me your attempts at criticism fall completely flat, as they are either factually incorrect or amount to "Python is different from [language x]".

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.

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

They may not have "a mental model of statically typed languages," but they sure "agonize" when there are eight different incompatible datatypes that represent a datetime and the library functions they want to use don't even specify which of these they take or return.

It's true that compulsory static typing can mitigate documentation bugs. But the effect isn't significant in the programming beginner experience.

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

Yes. But statically associating types to binding names does not relieve them of making and fixing these mistakes, it just makes it a runtime vs compile time error.

I am not sure if this is still the case today, but Computer Engineering in EE Department used to teach Pascal / Ada / C as the first programming language. With the expectation that making a program to compile correctly is hard. Before you move off to something like Perl / Java / Python.

While in CS they tends to start to Python or Java. And you start learning all the OO, Procedure or whatever paradigm before going into Web or other area of development with PHP. Where you get some results earlier.

I used to think EE way of teaching sucks. Old fashioned, not following the industry trend. Boring. Teaching you about OSI Models while CS students were already having some fun with the higher level Web Development.

Now I tend to think EE's way is far better.

I feel this. My CS program was in Java.

After a few years in industry, I believe that CS should start with either C or Scheme. C to teach you about real machines, Scheme to ignore the machine and do math (algorithms).

I get what you're saying, but learning C teaches you about the C memory model instead of "real machines". C was designed for portability across different architectures and, believe it or not, was considered high-level and abstract at one time.

But I agree that learning C is valuable because I believe that learning about manual memory management is valuable.

> But I agree that learning C is valuable because I believe that learning about manual memory management is valuable.

You need to do it in Ada too :-)!

And that's fair. I tend to view C as high-level assembler which does mean some loss of fidelity from pure assembly. It seems like a case of being "close enough", I suppose, because switching to pure assembly would make it a lot harder to cover the subject matter in a standard semester.

>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 has been going on for far too long, the whole "portable assembler" myth. IEEE694-1985 is a portable assembler, hell read "Using a high level language as a cross assembler" ( DOI: 10.1145/954269.954277 ), for that matter.

>and, believe it or not, was considered high-level and abstract at one time. The "gotcha!"-factor was increasingly ignored when I was learning about computer languages, but I had an advantage in having my first language be Turbo Pascal and self-taught using the manual and compiler.

> But I agree that learning C is valuable because I believe that learning about manual memory management is valuable. That's doable much easier in Ada, Forth, or BLISS. C is becoming more and more of a liability, to the point I would say that it has no real value in any professional setting, and an incredibly limited one in the academic.

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

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.

Pretty much all of my career has been in maintenance, so I tend to see the mess that gets made and while bad-design is always a killer, I notice there are languages that encourage/discourage it to varying degrees.

In the case of C, and other C-like languages, I most recently have four or five custom-made programs [some requiring specialized tools] that have little/nothing in the way of documentation: what it does, the "why-for"/motivation, any sort of high-level architecture-plan, or design-documents.

Fortunately for me, most of the programs actually do have documentation thanks to a true hero that left before I arrived.

I did some maintenance work on a fairly large C++ system that called into a custom lower level library written in C. Much of my work involved extending that lower level library. It processed several billion dollars a year in financial transactions, and was barely documented at all. It was intended to be "portable" so it had bizarre #ifdefs all over the place in case you happened to compile it on an ancient Unix with a K&R compiler from 1986. This was the early 2000's, so nobody ever did that. I doubt it would've worked, yet those #ifdefs remained "just in case."

The lower level C library was pretty clever. The original developer of most of it left about a year into my tenure there. He was one of the smartest guys I ever worked with.

The C++ "app" layer was a different story. The worst part it was a 3000 line switch/case block with about 100 different cases, chock full of copy-and-pasted code. It went on... and on... and on... I still have nightmares about it.

> The C++ "app" layer was a different story. The worst part it was a 3000 line switch/case block with about 100 different cases, chock full of copy-and-pasted code. It went on... and on... and on... I still have nightmares about it.

Ouch. That sounds brutal. If I had to do something similar, or maintain that, in Ada I'd leverage nested subprograms, local type/subtype definitions, and mandatory case-coverage — and I've done similar with VMs, particular opcodes — so you get something like:

    Type Opcode is ( NOP, Add_A, SUB_A, ..., Rem_D );

    Procedure Execute_Instruction( State : in out Machine_State; Instructions : in Instruction_Stream ) is
       Subtype A_Series is Opcode range Add_A..Sub_A;
       Subtype B_Series is Opcode range Add_B..Sub_B;
       Subtype C_Series is Opcode range Add_C..Sub_C;
       Subtype D_Series is Opcode range Add_D..Sub_D;
       
       Procedure Do_Add_A;
       -- other subprograms.
       
       Current : Opcode renames Decode( Next_Token( Instructions ) );
       --...
    Begin
       Case Current is
         when A_Series =>
           case A_Series'(Current) is
             when Add_A => Do_Add_A;
           end case;
         -- other series.  
       end case;
    End Execute_Instruction;

Of course you could structure it so that all the Do_OPCODE subprograms are local to the top-level switch, or local to the nested switches, as best suits the design; or decompose along 'families' of operation (Add_A, Add_B, Add_C, Add_D), but the important thing there is keeping things local/nested for maintainability.

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.

I started the other way round and came to Python long after I coded a lot in statically typed languages like Object Pascal, C++, Java, Scala and Rust. My feelings about Python are quite opposite to yours. I'm actually quite surprised how clunky Python is from my perspective.

I expected a small, simple beginner-friendly language, optimized for gluing stuff together, but I've found a huge number of overlapping features and idioms, more ways to do the same thing than in Scala, half-broken libraries with poor inline documentation, lot of "stringly" typed code everywhere where programmers don't seem to know other types than strings, ints and dicts, no ADTs / pattern matching, package version conflicts and all that with no help from the type system and unreliable help from IDE autocomplete.

Type annotations help a bit, but they are still far behind what's available in modern statically typed languages.

I've also run into a few things that were weirdly complex to do compared to other languages - e.g sending rest requests in parallel. Something I'd expect a glue language shine at.

It just feels like a major step backwards at least vs Scala and Rust which I used most recently.

So maybe it is a matter of earlier experience, familiarity and expectations?

Possibly lol. I find Rust & Scala to also require far too much boilerplate to get simple stuff done.

I suppose it depends on your intent. If you're writing a bunch of glue code, I seriously doubt Rust will be anywhere near as easy to reason about. Based on my own experience with the language, I can't imagine any coworkers ever grokking the language. Python on the other hand is picked up pretty quick. The beauty of Python is you don't need all that boilerplate nonsense like even having yo know what ADTs are or pattern matching or factory factory class. In Python, you just write code. A lot of people just have a few globals and a bunch of little functions and others use classes.

Maybe your domain is different? I might hate Python as much as you if I had to build a bunch of large backend code bases.

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 actually, despite Java being generally considered a verbose language:

https://blog.wolfram.com/2012/11/14/code-length-measured-in-...

> I seriously doubt Rust will be anywhere near as easy to reason about.

I find Rust easier to reason about because there are certain constraints on sharing mutable state forcing developers to keep to very simple data flows (complex data flows / dependencies are getting hard very quickly and the compiler will fight that a lot with you). Python has none of these, so reasoning about data structures that can be freely shared and mutated anywhere can be hard. Python needs a lot of self-discipline to not end up with unmaintainable code.

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 lots of sense when it comes to concurrency and systems programming, but that's not where Python shines or is meant to be used. In scripting, task automation, data science...etc it is really hard to beat. So maybe we're arguing over the usage of an axe and a sword on the battlefield and not about different swords lol.

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.

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

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

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

I think the winners in data science are Python, R, Matlab with Ada's share being non-existent. There is a reason for that. Ada doesn't have the numerical or data frame or stats libraries or any REPL functionality or charting libraries...etc. Language ecosystems are the thing that matters. I'd rather write Avionics or high speed trading systems in Ada, but data science? Maybe for some very niche problems.

> Ada doesn't have the numerical or data frame or stats libraries

Ada has a pretty nice set of numerics (Ada.Numerics.*), but the "lack of libraries" is almost a non-issue when the foreign-function interface is as simple as:

    Function Example_1(Item : Some_Matrix) result Some_Matrix
       with Import, Convention => Fortran,
            External_Name => "EX1";

> or any REPL functionality

There are a few people coming in from data-science who lament the lack of REPL, while I might do one, it's rather low on my list, though I think HAC is trying for REPL or something like it. (I haven't used HAC yet.)

> Language ecosystems are the thing that matters. I'd rather write Avionics or high speed trading systems in Ada, but data science? Maybe for some very niche problems.

I agree that the ecosystems are what matters, and this alone would be enough to fuel my general hatred of C: the amount of time, effort, and money spent on C, whether "making a better C" or crippling tools (eg text-diff vs real semantic diff) or making "it 'mostly' works" accepted is simply astronomical.

I think you've already stumbled on a little problem and that is one of using a FFI. Python's Numpy handles all of that for me, so I never have to leave the walked garden of Python. Many scientists/engineers have similar views and likewise have very little Fortran or C experience, so having the kitchen sink distribution with (import numpy) is preferable to FFI.

When I went to school the instructor talked a bit about Ada, but as far as I know there weren't any compilers available that mere students could afford. This was in the mid-90s.

I remember doing a bit of comparison of the syntax between languages, and Ada's lack of anything like a switch/case statement stood out, but the instructor did talk up the idea that if you could get it to compile it would run in Ada, assuming you didn't hit a compiler bug. Apparently getting the compilers working properly was a problem at the time.

I don't know when it was added, but Ada does have a switch/case equivalent construct and I can't imagine it wasn't available early on.

  case X is
    when 1 => ...;
    when 2 => ...;
    when 3 | 4 | 100 => ...
    when others => ...
  end case;

It was always part of the language, http://archive.adaic.com/standards/83lrm/html/lrm-05-04.html...

I have no idea what my professor was on about then. I remember him showing a slide of this ridiculous looking if/then/elseif... chain compared to a C switch statement.

I was at uni in 1995, they used gnat 3.15p.

> after my year they switched to either using Java or Python

They do this because of intense negative feedback from students who don't like having to learn languages for which there is no job market.

Which is fair, but also kind of funny. In theory, what most of us do day to day is software engineering and computer science is a niche corner of mathematics. But the broader expectation is that the math-niche teaches day to day programming.

I'm not sure this was the case for us, there were plenty of other courses in the major that involved both widely used language and more niche ones.

I think it was more that we didn't have enough professors who were bought-in to Ada to handle the volume of students in those initial courses. The professor who used to teach all the intro courses (and was the biggest advocate for Ada there) became the department chair and let other people take over those courses so he could focus what time he had on some of the upper level courses. Pretty sure they still use Ada in their concurrent programming course too.

Edit: Got curious and I think this is all the languages I used as part of an undergrad CS degree in approximately the order I first used them:

Ada, Racket, C, Make, x86 ASM, Java, Bash, batch script, PHP, JavaScript, MySql, Python 2, Inform 7, Blender Game Engine visual scripting, ICON, Lua, Erlang, and ROBOTC

I'm honestly surprised how much variety there was despite the only academic language being Racket.

There's something wrong with the idea that you go to college for a computer science degree just for the job market, and not the science. If getting a job is all that matters, surely a trade school or boot camp is the better route. But then I'm of the opinion that college shouldn't be in the market of mass producing future workers.

The problem is employers require computer science degrees, especially for entry level jobs. Then there's things like coding tests about inverting binary tries and such that tends to be less thoroughly covered in trade schools. When employers have more realistic demands we might see some change.

At the same time colleges are morphing into expensive trade schools, their advertising is full of phrases like "preparing you for the real world".

In Portugal it used to be relatively easy, do you want a degree with focus on the job market?

Polytechnic, with 3 years duration.

Do you want to learn to learn, and be prepared for any kind of challenge, with a professional title?

University, with 5 years duration

Now with Bologna, the rules changed a bit, however the universities sell the fact that now with 5 years the degree includes the master title, which used to require up to 3 years more on top of the 5.

As far as I am aware, other European countries have similar approaches, and in most of them in what concerns state universities, the biggest expenses are lodging, food and getting the required teaching materials.

I think there's a pedagogic void here. Everybody enjoys quick returns. be it a lisp repl, php f5 refresh or bash .. the desire to have clear mental model of your program state comes after (unless you have both brain power, talent and/or passion for that)

what school did you go to? My university (Radford) did teach Ada as well the first year, way back in 1999, and switched to Java after it.

I liked Ada a lot, but Java gave me employment after school.

They were teaching Ada in the Intro to Computer Science classes at Truman State in the mid-2000's as well. I think they eventually switched to Python sometime after I graduated 2008.

Western Washington University. I think they dropped Ada from the first courses in 2012 or 2013. Would be curious to see how those courses heavily featuring Racket have changed in the last decade while Racket was rapidly improving.

Ada was also taught at my Comp Sci program back in 1987

A lot of Universities and company's were bribed by Sun to start using Java.

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 now too, lots of platforms are buying user market share by offering free/cheap service for college students and reaping the revenue when the students move on / generate invites.

I wouldn't call this bribes but you can make an argument that it's buying mindshare that you wouldn't get on your own merits.

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.

Our university started to use Java right way in 1996 for compiler design and distributed systems.

Sun didn't need to bride our teachers, doing the same in C and C++ was such a pain with 1996 compilers and POSIX, that they didn't thought twice about changing into an interpreted language.

Reply on news.ycombinator.com