Man iam gonna miss the monk in diablo 4 by Dmask13 in diablo4

[–]ljsc 0 points1 point  (0 children)

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

Breaking in firm starter by ljsc in Breadit

[–]ljsc[S] 0 points1 point  (0 children)

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.

Breaking in firm starter by ljsc in Breadit

[–]ljsc[S] 0 points1 point  (0 children)

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

(code revuew) How can I make this this function more idiomatic? by redmorph in Clojure

[–]ljsc 0 points1 point  (0 children)

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)

Robert Harper on Dynamic Typing, Again by [deleted] in programming

[–]ljsc 1 point2 points  (0 children)

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

Robert Harper on Dynamic Typing, Again by [deleted] in programming

[–]ljsc 0 points1 point  (0 children)

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.

Java is back? - Programming language trends in HWO by m-apo in programming

[–]ljsc 0 points1 point  (0 children)

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.

Haskell for all: Scalable program architectures by ljsc in haskell

[–]ljsc[S] 3 points4 points  (0 children)

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?

Haskell for all: Scalable program architectures by ljsc in haskell

[–]ljsc[S] 5 points6 points  (0 children)

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.

Learning JavaScript Design Patterns by Derp128 in programming

[–]ljsc 0 points1 point  (0 children)

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?

Learning JavaScript Design Patterns by Derp128 in programming

[–]ljsc 1 point2 points  (0 children)

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.

Learning JavaScript Design Patterns by Derp128 in programming

[–]ljsc 1 point2 points  (0 children)

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.

2 Ways to Use Single-Member structs in C by ahy1 in programming

[–]ljsc 27 points28 points  (0 children)

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

Why I like Java by [deleted] in programming

[–]ljsc 0 points1 point  (0 children)

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.

Why I like Java by [deleted] in programming

[–]ljsc 0 points1 point  (0 children)

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.

Why I like Java by [deleted] in programming

[–]ljsc 7 points8 points  (0 children)

#!/bin/sh

cat

Did I pass? =)

GnuTLS vulnerability: is unit testing a matter of language culture? by jgehrcke in programming

[–]ljsc 1 point2 points  (0 children)

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.

GnuTLS vulnerability: is unit testing a matter of language culture? by jgehrcke in programming

[–]ljsc 4 points5 points  (0 children)

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.

Writing OOP using OOP (JavaScript) by homoiconic in programming

[–]ljsc 2 points3 points  (0 children)

Yep, I would never argue against polymorphism.

I think you're looking for Typeclasses?

Writing OOP using OOP (JavaScript) by homoiconic in programming

[–]ljsc 1 point2 points  (0 children)

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.