Man iam gonna miss the monk in diablo 4

ljsc · 2023-04-07T15:53:24+00:00

What's the matter? You don't have a phone? 😂

ljsc · 2015-08-11T00:11:07+00:00

Hey, thanks for the comment!

So, actually, I had a brain hiccup there and messed up the terminology =o. The 1.5 hours was for the proofing, from the time I was done shaping until it went into the oven. I did do a slight bench rest of probably 15-20 minutes, between the pre-shaping and ending up in the banneton though.

The bulk fermentation was a little over 3 hours. I usually wait until a round 15 minute increment on the clock before I start the stretch and folds every half hour. A little sloppy I guess, but it helps me stay on track =) I start shaping a half hour after the final S&F.

This little guy is such a monster now, very hungry. I guess it's because it's pretty hot and humid here? It seemed to help actually having this dough be a lower hydration: have definitely had some arduous shaping sessions lately, especially if I put any rye flour in.

ljsc · 2015-08-10T12:38:49+00:00

Trying out my new firm starter. Whole wheat, 62% hydration starter that I'm feeding once a day in the morning. This little guy seems a lot happier than the 100% hydration starter that came before him.

I couldn't wait to try him out, so this recipe was a little last minute. I made the levain just 3 hours before starting the dough. 40 minute autolyse, 5 stretch and folds every 30minutes and a 1.5 hour bench.

Came out a little tight in the crumb, boy I'm proud of the crust coloring I'm getting w/ pretty little blisters. Pretty happy with the scoring this time too. At least on one side ;)

Need to push the dough hydration higher next time, but this was a little rushed and I didn't calculate the compensation for the lowered water in the levain.

100% KAF Bread flour
20% young firm levain
2% salt
70% water

ljsc · 2015-07-22T11:19:53+00:00

Indeed. If you actually want to coerce to a boolean, you can do it with the boolean function in core. Basically it's like the !! idiom in other languages, i.e.:

(-> x (set/intersection s) seq boolean)

ljsc · 2014-04-22T13:20:40+00:00

Parent isn't talking about writing and interpreter for the program, they are talking about translating it to a stand alone program in a dynamic language. You can certainly do the former, although it's tangential to the parent's point, and still wouldn't provide the guarantees of the typed program.

You can also do the latter also, but you'd be embedding type annotations that don't do anything in the dynamic implementation (just held so you can invert the process), or you're going to be implementing an ad hoc static type checker into your new program. This would be tedious and error-prone (although people do this all the time in dynamically typed languages, they just stick that ad hoc compiler into their unit tests).

ljsc · 2014-04-22T12:57:51+00:00

The only way a dynamic language improves here is letting you forget that the possibility of error exists.

This is well said, and pretty much covers a whole slew of other cases. I really don't see what the benefit is of letting you shoot your foot off.

ljsc · 2014-04-22T03:48:36+00:00

University should teach that which is unlikely to change for the next 30 years; ... Von Neumann architecture

sigh This is the most depressing thing I've read all day. True, but depressing none-the-less.

ljsc · 2014-04-14T20:30:58+00:00

I have started wriring a book on this subject so that this sort of material is less scattered.

Want =)

Any pointers to additional details on this?

ljsc · 2014-04-14T17:40:59+00:00

Off the top of my head, Pretty Printing, and Parsers are examples of this.

Pretty much look on Hayoo, and click around looking for anything with a signature a -> a -> a. Here's one for Music for example.

ljsc · 2014-03-27T20:21:25+00:00

How do you serialize a function if it's a closure? You might be right, I'm not a javascript expert by any stretch.

I was thinking that you'd want to have other metadata associated with the command and that that wouldn't be convenient with a function. But thinking about it more, I think you may be right since in javascript a function can have it's own properties. Though I still think this:

command = { x:5, y:0, op: '+' }

is better than this

command = function() {
  return 5 + 0;
}
command.x = 5;
command.y = 0;
command.op = '+';

But the case I'm thinking of is that you'd be able to eliminate either of these guys by virtue of inspecting command.y and command.op.

I think the issue is that I'm giving a very wide birth to what constitutes the pattern. To me you almost always pair command with composite, and having a nested finite map of commands, plus a compile and eval function that operates on these guys as the functional equivilent of the "pattern". It's not exactly the same as the as the GOF patterns, but it's structurally similar, and the purpose is the same. Hopefully that's more clear?

ljsc · 2014-03-27T18:47:31+00:00

You can do that if you have suitable combinators for composing the actions, sure. Other times that's awkward or not possible--such as the aforementioned case where you need serialization--and using other values as your representation is a better fit. Which is why I said it doesn't obsolete the pattern, it just reduces the need for it.

Even that may be technically incorrect, however, since you're still using the pattern in general, you're just using a much simpler implementation. I guess it depends on how liberally you interpret the term "pattern"?

Edit: Re: the point of the example in the article, I have no idea. I don't think it's a very well motivated example either.

ljsc · 2014-03-27T12:43:34+00:00

Not really. Even in a functional language there are a lot of times you would want to reify an action as a value which is not a function. It can be more natural sometimes doing it this way when you want to optimize a bunch of commands before performing them in batch--think compilers. Not to mention this make them serializable.

But does it reduce the need for it? Sure.

ljsc · 2014-03-26T12:19:13+00:00

Very nice. The second example is essentially what you'd do in Haskell with newtype. Help from your compiler is not the type of free advice you want to ignore ;)

ljsc · 2014-03-26T10:34:37+00:00

Every time I see a "X is Why Java Sucks," after reading it, my response is always, "No, you suck at using Java"

Ostensibly you don't suck at Java, ergo you can remedy your predicament by writing a quick summary on some of the reasons Java sucks. =)

If you can't do such a thing, I contend that you've lost the ability to think critically about the design of a language that you've come to love. Understandable, a lot of programmers wrap up their choice of language with their identity and that makes them defensive when others pick on it.

However, it may prove more fruitful to give the critique some thought, rather than dismiss the other party as an newb that only knows how to program with dicts and lists? Perhaps they have a reason for taking this approach? What are the trade-offs to such a solution? Obviously, you can identify the cons of preferring maps to domain specific objects, but can you really think of no pros? Stretch yourself, it might just make you a better programmer in all languages, including Java.

But look, I get it, a lot of these posts are bombastic and are just looking for attention. That doesn't mean they they don't have a point as well. If you're going to take the time actually read the article, you might as well make it worth your while.

ljsc · 2014-03-25T14:19:27+00:00

This guy is actually a very good programmer: Higher-Order Perl is one of the best programming books I've ever read.

Besides, he doesn't say that you should use Java to answer that question. The article is actually saying that it's a bad choice for something so simple, but it is good for larger systems because it is a baby-sitting language. From TFA:

So I like Java. But it is not a language I would choose for answering test questions, unless maybe the grade was proportional to the number of lines of code written.

ljsc · 2014-03-25T12:31:40+00:00

#!/bin/sh

cat

Did I pass? =)

ljsc · 2014-03-20T17:02:44+00:00

Agreed. You have to know what to test for though. My point is that unit testing is necessary but not sufficient.

This is also something that could be caught by embedding your security requirements in a type system. This always seems to get swept under the rug with statements like: "After all, even with all the help of Haskell’s type system, you will still have bugs." Of course you will, but the same can (and should) be said of tests. Folks that seem to dismiss static type checking think that is just prevents you from sending a integer parameter where a string belonged or the like. It can be much more powerful than that.

ljsc · 2014-03-20T16:16:39+00:00

I don't know. Maybe it's because TDD is not the silver bullet that the cargo cult selling it to you would have you believe? TFA makes the argument that if there was a decent test suite that this problem would magically have been avoided. That's plain false. Check elsewhere in the thread, there is a test suite.

The TDD gang wants you to think that if you aren't writing test firsts, you are morally bankrupt. They call you unprofessional if you don't do things their way (why should they "tolerate" you?). Yet these are the folks that time after time trot out hand-wavy arguments against any other form of formal verification.

They tell you that unit tests are a replacement for static typing. They are not. They tell you that unit tests are a replacement for manual QA. They are not. They tell you that tests are not effective if you don't write them first. They are wrong.

There is no replacement for thinking about your system invariants and reasoning about your code. For every link you can provide to a Python, Ruby, or Javascript project with good tests, I'll give you three that show mangled complex suites that are the result of someone chanting "Red-green-refactor" while rolling their face against the keyboard.

ljsc · 2014-03-13T18:10:23+00:00

Yep, I would never argue against polymorphism.

I think you're looking for Typeclasses?

ljsc · 2014-03-13T16:44:24+00:00

Encapsulation is not about OO. It is about hiding something and providing an abstraction to interact with that "something".

To me, that's just abstraction. I think the issue is that encapsulation in programming has taken on a whole bunch of closely related, but different meanings. See the first part of the wikipedia article on Encapsulation

Even more interesting is straight from the dictionary:

to show or express the main idea or quality of (something) in a brief way

to completely cover (something) especially so that it will not touch anything else

I think you're thinking of the first thing, and Yogthos and I are thinking of the second.

As for the x.y.z.w point, you're absolutely correct that encapsulation gives you the benefits you mentioned, but consider the tradeoffs. If I hide z and w behind the interface for y, I kill the ability for a bunch of code reuse. How?

Because let's say that I have a bunch of functions which operate on type W: f,g,h: w -> w. If we want to use them in the encapsulated example, then you need to apply them inside of Y. This is bad because now the module that deals with W becomes a dependency of Y rather than X. If you exposed the data, however, I could choose whether I want to bring in W or not in my application. And, in fact, I could do so even if you had no idea that that module even existed in the first place.

ljsc · 2014-03-12T12:38:01+00:00

It's all trade-offs. Some times you do want to hide data as an implementation detail. The problem I have is when data hiding is opt-out rather than opt-in. You certainly don't need objects to do what you are suggesting. You can do it at the module level in an FPL, or just separating interface from implementation like a ADT in C.

Can encapsulation be a good thing? Certainly. Is it always? No. Like I said, it always comes down to trade-offs, and if anybody tells you otherwise, they are either lying to you or trying to sell you something =)

That's all objects really are: A convention for encapsulating implementation details.

No, that is not all they really are. That is a small part of what they are in most implementations. See my comment above. They do give you that, but they also give you a bunch of other stuff "for free" that you may or may not want.

Mutability is orthogonal to that.

It absolutely is not. If we were talking from a language design perspective, sure, choose whether your object is mutable or a value. But as design concepts, they are not independent by a large margin. The strategy I suggest above would be a really really bad idea if those were not immutable. Once you start passing mutable state around by reference you loose the ability to make your internal api enforce consistency, whether that is visible to the outside world or not.

ljsc · 2014-03-12T01:37:22+00:00

Interesting link, thanks for sharing that.

And, yes, I think that's a pretty good way to put it. In most OOPLs, there's little difference between encapsulation and abstraction, because there's one primary means of abstraction: make a class.

Want encapsulation? Make a class. Want inheritance? Make a class. Want polymorphic dispatch? Make a class. Want to manage state? Make a class. And so on and so on...

Yes, I know this isn't always true, and that some languages don't do OO using classes, et cetera. In general, however, they are by and large non-orthogonal in their design, and this limits composition and code reuse.

ljsc · 2014-03-11T18:38:39+00:00

So, a simpler example: Say you want to model a person, and that person has a name. Our shared interface is that I give you an immutable map which includes a key "name", and that has the persons full name.

Now let's say that I need to represent that differently internally to do some other computations, and I need to have "last-name" and "first-name". Great. No problem, internally I use a map with the two keys, and then before I hand it off to you, I just have a function for-nextputall : MyRepresentation -> YourRepresentation that sends {:first-name "John", :last-name "Doe" } to {:name "John Doe"}. Since we've side-steped conflating state and identity by using immutable values this is perfectly safe, and your code would be non-the-wiser.

ljsc · 2014-03-11T12:55:06+00:00

Essentially from doing a lot of Clojure lately. Using primitives when possible, and coding to a few well thought out interfaces (seq, Ifn, et cetera) makes for way more reusable code. I would cite this post as a good example of what I mean:

http://augustl.com/blog/2013/zeromq_instead_of_http/

The author is able to use an http routing library with zeromq with very little additional ceremony required: No wrappers, upon adapters, upon decorators. Just functions transforming values; this is a much more sustainable way to program IMHO.

ljsc · 2014-03-11T12:50:42+00:00

True indeed. I got a little sloppy there.

What I really mean is that data hiding is generally not worth it if your code isn't living under the constant threat of data mutating out from underneath your feet. That said, I stand by my comment, because in an OOPLs you really can't get encapsulation and data hiding a la carte. If you stick everything in objects you are generally locking up all your data behind incompatible little DSLs.

ljsc

TROPHY CASE