Live data from Hacker News

Write More Classes

lucumr.pocoo.org

21–30 of 150 posts

Re: Write More Classes

#21
As Java was mentioned. The Java API is very nice, but there is a layer missing on top. The Java API was written with a early 90s mindset and got most users after 2000. This goes for most Java APIs. IO, Swing, ... The idea is to have LEGO building blocks (BufferedReader) you can plug together. But you need to plug them together all the time. The missing layer e.g. is IO.readIntoString(file). Apache IOUtils, StringUtils etc. fill in this layer for many Java APIs.

The one API that is not powerful enough is Collection. There you have the top layer without the LEGO building blocks. Compare this to the Scala collection API which has the top layers and the building blocks.

For a good API you need both, building blocks to tailer to your specific need (20% of the time) and an easy top layer (80%) to prevent writing the same stuff all the time.

Re: Write More Classes

#22

if classes didn't have such a terribly verbose syntax in basically every language that has them, i'd be less opposed to using them. in java, c++, or c#, to add a variable to a class, you have to repeat its name 4 times. once to declare, once in the constructor parameters, and once on each side of the assignment. why am i writing the same thing 4 times for what should be a core part of the language? in haskell, you wr…

FWIW, with C#'s object initialisation syntax you can cut that down to once too. eg public class Foo { public string Bar { get; set;} } var foo = new Foo { Bar = "Hey there" };

I've come to love Scala case classes:

  case class Foo(bar: String, foo: String = "hello")
  new Foo(bar = "Hey there")
  new Foo(foo = "Hey there", bar = "Hello")
  new Foo("Hey there")

Re: Write More Classes

#23

if classes didn't have such a terribly verbose syntax in basically every language that has them, i'd be less opposed to using them. in java, c++, or c#, to add a variable to a class, you have to repeat its name 4 times. once to declare, once in the constructor parameters, and once on each side of the assignment. why am i writing the same thing 4 times for what should be a core part of the language? in haskell, you wr…

I get what you're saying, but good OO for me usually suggests nullary constructors, letting a class know when something happens as opposed to setting internal state directly, and the class saying let me do something for you using my state instead of giving you my state directly.

Providing a getter at least is sometimes practically unavoidable, so there's 1 repetition, but with a good IDE that's just a quick key combination over the variable name.

Re: Write More Classes

#25
This is a bad article.

First, write nothing. If you can solve your problem without writing code (or even better, by deleting code), that is the best solution.

Next, write code which fits your architecture. Sometimes functional composition is the best system for representing your computational structure. Tree operations, for example, are especially amenable to recursive function-based computation.

Sometimes, when you are writing a state machine, for example, an object is the best possible representation. Objects are entirely focused around hidden-implementation finite state machines, and thus mirror your computation almost exactly.

Funny how most people who have only practical training in a handful of languages and no programming language theory at all tend to advocate for the one style of programming that they know well. When all you have is a hammer...

Note: The small paragraph at the end of this article seems to hedge by agreeing with me and essentially calling the reader to disregard what he previously wrote. If he had followed my step one he could have avoided writing the entire article. Think of the complexity saved!

Re: Write More Classes

#26
So in Java, a parameter named 'filename' is automatically aliased to 'path'? Doh...

static String readFirstLine(String filename) { try { BufferedReader br = new BufferedReader(new FileReader(path)); ....

So people writes this everyday, yet still fail to do it correctly...

Also, this article was written 1 day in the future. The future looks bleak to me...

Re: Write More Classes

#27

This is a bad article. First, write nothing. If you can solve your problem without writing code (or even better, by deleting code), that is the best solution. Next, write code which fits your architecture. Sometimes functional composition is the best system for representing your computational structure. Tree operations, for example, are especially amenable to recursive function-based computation. Sometimes, when you…

From what you wrote, I'm not sure you read the article. It's not about objects vs functions; it's about hiding a lot of functionality behind an overly-simple interface, with particular attention paid to an example of a parser that takes a whole string rather than a streaming interface.

What annoyed me most was his constant apparent conflation between bytes and characters. But I didn't really see much evidence of treating all the world like a nail.

Re: Write More Classes

#28
post #23

if classes didn't have such a terribly verbose syntax in basically every language that has them, i'd be less opposed to using them. in java, c++, or c#, to add a variable to a class, you have to repeat its name 4 times. once to declare, once in the constructor parameters, and once on each side of the assignment. why am i writing the same thing 4 times for what should be a core part of the language? in haskell, you wr…

I get what you're saying, but good OO for me usually suggests nullary constructors, letting a class know when something happens as opposed to setting internal state directly, and the class saying let me do something for you using my state instead of giving you my state directly. Providing a getter at least is sometimes practically unavoidable, so there's 1 repetition, but with a good IDE that's just a quick key combi…

> good OO for me usually suggests nullary constructors

I'm curious, could you please elaborate on this point? If a class has any dependency, i usually find it better to require that dependency to be passed in the constructor, so the constructed instance can always be in a valid initialized state. Why do you find nullary constructors to be good OO?

Re: Write More Classes

#29
post #10

IMO, the Flask example is pushing it - considering how large a job rendering a template is, the number of customization points is probably appropriate, but at some point you're going to get lost in a rabbit hole of wrapper functions that call wrapper functions and end up with three equally appropriate levels you might hook into because the code was written to keep you from having to duplicate a single line of code fr…

Some note: When it comes to debugging I've rarely seen a better stacktrace output than the one Flask presents you in debug mode (provided by Werkzeug). It actually lets you open the damn sourcefile right there. Right now I'm (mis?)using Flask together with CouchDB to build a db application where you can dynamically define your entities, fields, code hooks and so on at runtime and using Flask for this has been great so far. Ronacher's attitude clearly shows through in how easy I could get Flask to behave in ways it was possibly never meant to (dynamically add view definitions, document mappings and so on).

So Armin, if you read this, thank you, it was a joy spending time with your framework (and source code) over the weekend ;)!

Re: Write More Classes

#30
post #23

if classes didn't have such a terribly verbose syntax in basically every language that has them, i'd be less opposed to using them. in java, c++, or c#, to add a variable to a class, you have to repeat its name 4 times. once to declare, once in the constructor parameters, and once on each side of the assignment. why am i writing the same thing 4 times for what should be a core part of the language? in haskell, you wr…

I get what you're saying, but good OO for me usually suggests nullary constructors, letting a class know when something happens as opposed to setting internal state directly, and the class saying let me do something for you using my state instead of giving you my state directly. Providing a getter at least is sometimes practically unavoidable, so there's 1 repetition, but with a good IDE that's just a quick key combi…

I don't think that nullary constructors are so good. If you have dependencies then after constructing your object it'll be in an invalid state because the dependencies aren't set up correctly.
Post reply on HN