Live data from Hacker News

Ask HN: What made you change your mind about a programming language/paradigm?

news.ycombinator.com

171–180 of 401 posts

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#171
post #122
post #115

General hardware. I used to do all my work on dedicated hardware with support for Lisp (CADRs, 36xxs, D-machines, and before that PDP-10s) because those general purpose machines couldn't implement important features like generational garbage collection without specific hardware assist. Then one day in 84/85 I saw a generational GC using the MMU on a 68K and the light dawned. Thus while I'm pretty interested in ML chi…

I wouldn't bet on the ML hardware startups either, but don't you think that what we regard as general hardware is always going to be too heavyweight to be suitable for massive parallelisation?

Well, take a system approach to the hardware. It's possible you could have multiple paths to memory. It's more likely you won't on non-high-end-systems. The primary path will for the CPU, especially on mobile.

Also look at the workload: often many of the primary cores will be idle when you're crunching a big dataset.

Those two factors suggest that you want to use CPU hardware for mult-add fops, especially when you consider using smaller float sizes (not just f16 but even f8). And then you consider that the compiler can perhaps properly interleave these ops with the regular instruction mix...

This is who general purpose von Neumann architectures ate hardware, both RISC and CISC.

Now the current crop is pretty dire (e.g. AVX* is hard to use with a typical workload) but perhaps these won't be typical workload? Or the power/timing problems will be solved other ways.

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#172

Testing. Unit testing to me seemed akin to drinking 8 glasses of water every day. A lot of people talk about how important it is for your health, but it really tends to get in the way, and it doesn't seem to really be necessary. Too frequently, code would change and mocks would need to change with it, removing a good chunk of the benefit of having the code under test. Then I started writing integration testing while…

I think most would agree that integration tests are better. The problem is they tend to be slower. Having to initialize the system appropriately for every test (e.g. writing to the database) tends to limit the number of tests you can have. Unit tests scale a lot better. That's why most generally use a pyramid structure: lots of unit tests, a moderate amount integration tests, and a few end-to-end tests.

An approach of “almost” integration tests can be much faster. I.e. rather than spinning up a full-blown web server or database, use fake objects for those. Uncle bob describes refactoring the architecture of a project to make integration tests faster by decoupling the web server.

Mentally, something like clojure’s ring framework make this easier to grasp: the abstraction it provides is dictionary-in, dictionary-out. Once you have something like this, there’s no need to spin up a web server to do integration testing: you just shove a bunch of dictionaries and and make sure the output dictionaries are what you expected.

A good approach is to use each technique where you get the most bang-for-buck: use unit tests only for pure functions, and decouple your system in a way that integration tests can be reduced to simple data-in data-out (which also makes them very fast)

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#173

Earlier quoted context omitted.

I think most would agree that integration tests are better. The problem is they tend to be slower. Having to initialize the system appropriately for every test (e.g. writing to the database) tends to limit the number of tests you can have. Unit tests scale a lot better. That's why most generally use a pyramid structure: lots of unit tests, a moderate amount integration tests, and a few end-to-end tests.

An approach of “almost” integration tests can be much faster. I.e. rather than spinning up a full-blown web server or database, use fake objects for those. Uncle bob describes refactoring the architecture of a project to make integration tests faster by decoupling the web server. Mentally, something like clojure’s ring framework make this easier to grasp: the abstraction it provides is dictionary-in, dictionary-out.…

Ah I forgot the link https://youtu.be/WpkDN78P884

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#174
post #81

Using it as my main language: Python (2.7). How the hell did this thing become so popular? I've used it for all sorts of stuff earlier, less complex than the other. Scripts, devops, ETL... But then I got into a company that is using it for some quite serious stuff, a large codebase. Holly smokes this thing does not scale (in terms of development efficiency and quality) well. I swear at least 70% of our bugs is becaus…

I've used it at in a few jobs. Once place, mostly a Java shop, used it almost exclusively in a system that had grown to the point that it'd be hard to replace. The most insightful comment I got about it was that it's not that Python doesn't scale in terms of service instances or performance--it doesn't scale with codebase size and onboarding new developers.

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#175
post #142

Earlier quoted context omitted.

> "all the services needed to talk to each other" I'm not an expert by any means, but I'm pretty sure that statement indicates a problem.

Yes, then you're just doing bad OOP with sockets instead of a language that was designed for it.

Heh, definitely some truth to this.

What saved us before, was our forest of code could depend on the database to maintain some sanity. And we leaned on it heavily. Hold a transaction open while 10,000 lines of code and a few N+1 queries do their business? Eh, okay, I guess.

Maybe we didn't have the descipine to make microservices work. But IMO our engineering team was pretty good compared to others I've seen. All our "traditional" apps chugged along fine during the same period

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#176

Immutability. I didn't really understand the benefits of having immutable data structures until I tried building a service with no mutations whatsoever... and noticed I didn't get any weird, head-scratching bugs that took hours to reproduce and debug. That led me to go down the Functional Programming rabbit hole - thus changing my entire view on what code is/could be. [edit: spelling]

To add to this: functional programming. Getting rid of state in objects was a DREAM for me. I used to think: come on you better than though hipsters... this shit looks ridiculous, and it isn't intuitive... There's no way it's worth it to learn. It's just the new fad. Oh, how I was so so wrong.

Tell us what was your starting point and references used to learn FP

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#177
post #94
post #81

Using it as my main language: Python (2.7). How the hell did this thing become so popular? I've used it for all sorts of stuff earlier, less complex than the other. Scripts, devops, ETL... But then I got into a company that is using it for some quite serious stuff, a large codebase. Holly smokes this thing does not scale (in terms of development efficiency and quality) well. I swear at least 70% of our bugs is becaus…

I've mostly done Java in my career and I tend to stick to it (or Kotlin now). I've always said the power of java isn't in solving programming problems, it's in solving organizational problems. The killer feature that vaulted it to the top and still hasn't been beat is javadoc.

Not javadoc the standard, but javadocs for the standard library. It explains behavior in much more detail than other languages' docs, so I'm rarely surprised.

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#178

Types, because of testing. Python code is really hard to maintain once you grow over a few thousand lines of code and a few developers. I used to believe that a good culture and seasoned developers can delivered testable code, but it rarely happens in practice. Even if, deadlines kill testing budget. Types make refactorings sane, they are you contracts. Ended up in Haskell.

http://mypy-lang.org/

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#179

My first big Erlang project made me completely rethink my acceptance of object oriented programming in C++, Java, Python, etc. I realized that I had blindly accepted OO because it was taught as part of my college curriculum. After several years in industry I had concluded that programming was just hard in general. It wasn't until my first project in Erlang, where an entire team of OO devs were ramping up on functiona…

Same reaction but different type of project and language. Immutable data with persistent data structures was a game changer for me. There is place for OO but it does feel like the last 20 years our profession has been suffering from collective insanity.

Try code large a GUI project without OO.

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#180
post #144

Static Type Checking. I used to think Node.js was the greatest thing ever. I won't bother explaining the benefits but suffice it to say I much prefer writing a server in Java compared to node. I think it takes getting burned at least once for new developers to understand why a lot of seasoned developers like types. Over time I've realized that there's a simple principle that applies to a lot of stuff in software and…

Good insights. Modern platforms are neither full dynamic nor rigidly static, but gradual, https://en.wikipedia.org/wiki/Gradual_typing . Start with a dynamic script, add typing as you go to strengthen the system. Notable mentions: Typescript, Python + mypy, C#, Dart.

This doesn’t encompass all modern platforms, just those that decide to go that route.
Post reply on HN