Live data from Hacker News

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

news.ycombinator.com

361–370 of 401 posts

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

#361

Earlier quoted context omitted.

It's changed fundamentally since 2.2... Also if you're fixing broken Python code, you're using Python, so no that doesn't really track.

You know, sometimes people have to fix trashfires; that doesn't mean they'd start one. What fundamental changes do you see since 2.2? If you're talking about the object model; objects in python were garbage before and after 2.2, and as a paradigm, it's mostly useless bureaucracy. Bleeding edge 90s ideas.

Sorry but yes, if you're fixing "trashfires" in python, you're using python.

And the literal introduction of objects does fundamentally change a programming language.

Honest question: How old are you?

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

#362
Java/JVM perception changed by learning Clojure.

I did a lot of Java/Android/Hadoop back in college and honestly was under the impression that Java was for legacy enterprise apps, and college classes. With the exception of Android, I felt that it's prevalence was dying as many companies are using MVC type of products in simple frameworks like Django and Rails now.

I was a little disenchanted that I had to do so many assignments in Java in college, then I found Clojure.

My entire programming mindset has changed after working with a FP language, in my case, Clojure. This has got me more excited about the JVM than ever before because I see it as having new abilities I didn't see before, and the added benefit of great libraries that have been rigorously tested.

I highly recommend learning a LISP. A great beginner starting point is CLojure with Clojure for the Brave and True as a way to learn. The other go to is Structures and Interpretation of Computer Programs which is in Scheme.

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

#363

Earlier quoted context omitted.

You know, sometimes people have to fix trashfires; that doesn't mean they'd start one. What fundamental changes do you see since 2.2? If you're talking about the object model; objects in python were garbage before and after 2.2, and as a paradigm, it's mostly useless bureaucracy. Bleeding edge 90s ideas.

Sorry but yes, if you're fixing "trashfires" in python, you're using python. And the literal introduction of objects does fundamentally change a programming language. Honest question: How old are you?

You very obviously didn't use pre 2.2 python. There were objects. They were shit! They were shit afterwords!

I'm guessing based on your incredulity about 15 or 20 years older than you.

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

#364

Earlier quoted context omitted.

Sorry but yes, if you're fixing "trashfires" in python, you're using python. And the literal introduction of objects does fundamentally change a programming language. Honest question: How old are you?

You very obviously didn't use pre 2.2 python. There were objects. They were shit! They were shit afterwords! I'm guessing based on your incredulity about 15 or 20 years older than you.

Our age difference explains a lot of your recalcitrance towards new (to you) things.

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

#365
I got into Haskell a while back and dove deep into the purely functional, strongly typed, category theory rabbit hole. This small but very hard-core community exposed me to completely different (and radical) ideas about programming, software engineering and PL design after I was sure I've seen everything under the sun when it comes to PLs. I soon turned into one of those annoying zealots that keeps preaching functional programming. After a while, I wanted to write my own language/s and set out to build a compiler in Haskell, I kept wanting to make it more and more general brushing against the edges of what the type system could handle and thinking in more and more abstract category theory terms until I just gave up. I felt that the type system was restricting my thinking. Another example of this absurdity in the Haskell way of thinking is a very general scala library: https://github.com/slamdata/matryoshka .

TL;DR: Haskell makes you think in a deep, general and often very beautiful mathematical way which makes you write beautiful but unintelligible code for the non-mathematician programmer.

The switch came when I became increasingly fascinated by machine learning (which is written mostly in Python). Programming in Python felt extremely liberating to me, I could express complex ideas with minimal number of lines that was also obvious for others to read. This is not to say that I abandoned the ideas I learned from the functional land, on the contrary, I still think in a very functional way and Python only made it so much easier to express those concepts. A powerful middle-ground between the two approaches is gradual typing (ie. mypy or typescript) which lets you take advantage of type checker without letting it get in your way, this is the best of both worlds for me.

TL;DR: Strong types are for weak (or lazy) minds. Python FTW.

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

#366

Earlier quoted context omitted.

You very obviously didn't use pre 2.2 python. There were objects. They were shit! They were shit afterwords! I'm guessing based on your incredulity about 15 or 20 years older than you.

Our age difference explains a lot of your recalcitrance towards new (to you) things.

It amazes me that you dismiss someone with 20 years more experience than you as somehow knowing less.

Python isn't new to me: it's old, and it's crap, and its "evolution" is towards a dead end. Stuff like nodejs will eventually supplant it if it hasn't already, and with good reason (not that I am a huge fan). Python was a novel design and a great choice ... back in the 90s. I mean, use it if you like it; use Forth or Lua or whatever you like. I think it's terrible and should be abandoned wherever possible.

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

#367

Earlier quoted context omitted.

As the other commenter already pointed out, functional reactive programming wiped the floor (React) of OO style approaches to GUI design. It turns out thinking about interfaces is made considerably easier with one way data flow.

If you’ll open https://reactjs.org/ you’ll read right on their main page: > Build encapsulated components that manage their own state, then compose them to make complex UIs. Components managing their own state is a textbook definition of OOP. They even use inheritance in their example on the main page: > class HelloMessage extends React.Component

React isn't really object-oriented. Components rarely pass messages to each other. Instead, the way that data flows is through function/constructor arguments. You can directly invoke a method on a component, but that's only really used as an escape hatch. It's inconvenient, and IMO, a code smell.

For the React that I write, class components are used only when there's some trivial local state that I don't want to put into Redux (e.g. button hovering that can't be done in CSS), or when I need to use component lifecycle methods.

And yes, class components do inherit from React.Component, but they specifically discourage creating your own component base classes.

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

#368

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 have the same experience. Integration tests are the best. They test only what really matters and allow you to keep flexibility over implementation details. When your TDD approach revolves around integration tests, you have complete freedom to add, remove and shift around internal components. Having the flexibility to keep moving around the guts of a system to bring it closer to its intended behavior is what softwar…

[deleted]

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

#369

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 have the same experience. Integration tests are the best. They test only what really matters and allow you to keep flexibility over implementation details. When your TDD approach revolves around integration tests, you have complete freedom to add, remove and shift around internal components. Having the flexibility to keep moving around the guts of a system to bring it closer to its intended behavior is what softwar…

I'll would like to watch you running around and trying out everything when integration tests fails and you don't know which part of the code base caused the failure, while I just run all the specs and figure out the exact unit of code that is causing the problem.

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

#370

Earlier quoted context omitted.

I have the same experience. Integration tests are the best. They test only what really matters and allow you to keep flexibility over implementation details. When your TDD approach revolves around integration tests, you have complete freedom to add, remove and shift around internal components. Having the flexibility to keep moving around the guts of a system to bring it closer to its intended behavior is what softwar…

I'll would like to watch you running around and trying out everything when integration tests fails and you don't know which part of the code base caused the failure, while I just run all the specs and figure out the exact unit of code that is causing the problem.

That would not happen because each of my integration test cases are properly isolated form each other. If any specific test case starts failing, I just disable all other test cases and start debugging the affected code path; it usually only takes me a few minutes to identify even the most complex problems. Also, because I use a TDD approach, I usually have a pretty good idea about what changes I might have made to the code which could have introduced the issue.

Unit tests on the other hand are useless at identifying complex issues like race conditions; they're only good at detecting issues that are already obvious to a skilled developer.

* I restart the system from scratch between each test case but if that's too time-consuming (I.e. more than a few milliseconds), I just clear the entire system state between each test case. If the system is truly massive and clearing the mock state between each test case takes too long, then I break it up into smaller microservices; each with their own integration tests.

Post reply on HN