News for hackers. Stuff that matters.

opvasger

Re:Moving Away from UUIDs on Tuesday November 22, 2022 @01:24AM (#33702693)
UUID, as the name implies, is used for identifiers - You know this.

These use-cases you're implying seem to be the real problem.

unreadable title - jesus! :P
Re:Java in the Browser on Tuesday August 23, 2022 @08:45AM (#32564078)
it's sort of funny - I expect Java in the browser not to work well (as it didn't, historically)... And sure enough - the site returns a 502 error :P
Re:The real world is mutable – consequences for system design on Saturday February 01, 2020 @03:54PM (#22213161)
provocative blanket statements like "the real world is immutable" (or otherwise) aren't correct, nor healthy.

Some problems are more easily dealt with using tools like immutability, or mutation for that matter.

as with all things in software - it depends.

Re:How to Build Good Software on Monday August 19, 2019 @04:50AM (#20736058)
> The root cause of bad software has less to do with specific engineering choices, and more to do with how development projects are managed.

...While I do agree that "project-management" is important, I think the tools we are using today are really underpowered to deal with complexity/human-error - Which is the bigger problem IMO.

I have a beef with the title of this library...
When people write "persons", my head starts spinning.
Re:JS Paint – A web-based MS Paint remake on Thursday January 18, 2018 @02:40AM (#16175393)
YES - thank you!
My clients get to render their own html - it's not really that bad if you bundle, split and cache the code.
Re:We have a pretty good idea of when humans will go extinct on Saturday October 07, 2017 @11:58AM (#15424260)
Fear-mongering?
Re:Why We Chose Typescript on Friday June 30, 2017 @07:56PM (#14674344)
I'm coming at this from the Elm-camp, and my first impression (and largely why I think languages like Elm is promising) is how languages that are implemented as supersets of other languages have the potential to be as bad as their subsets.

The example that I was given was C++ and C, but I think TypeScript with it's gradual-typing approach is forced to remain potentially as bad as JavaScript itself - that is, if you're feeling weak and want to "get shit done", you can bypass all the goodness that TypeScript undeniably offers you.

For a language like Elm, the type-system is invariably gonna have your back - a value-proposition I think means a lot more in practice than some self-proclaimed pragmatists realize :)

Re:Why OO Matters in F# on Thursday March 23, 2017 @07:10PM (#13945181)
Haha - I'm simply stating that I'm excited to do it and not for it to be possible :P
Re:Why OO Matters in F# on Wednesday March 22, 2017 @04:37PM (#13934677)
C# & Java has anonymous functions, but not 1st-class functions AFAIK

EDIT: but then again, they truely are of no use :P hehe

Re:Why OO Matters in F# on Wednesday March 22, 2017 @04:36PM (#13934660)
I'm excited to use higher-order functions in C someday :)
Re:Why OO Matters in F# on Wednesday March 22, 2017 @11:36AM (#13931748)
I don't think annonymous functions have anything special to do with FP or OO for that matter. Maybe someone can fill in on this?

In my mind, functional programming is about programming with mathematical functions - Purity - No arbitrary effects being thrown around - Input to output... Ba-Da-Boom-Ba-Da-Bing.

I find this much more valuable as a restriction from the runtime than as a guideline that can be ignored whenever deemed convenient.

That being said, I wouldn't have a job if I couldn't compromise on this :(

Is there any way to enforce some purity in F#? Does the type-system annotate effectfulness?

Re:Is Semantic Versioning an Anti-Pattern? on Wednesday January 11, 2017 @07:52PM (#13378981)
This seems inspired and perhaps even duplicated from what Rich Hickey recently said about Semantic Versioning (found here: https://www.youtube.com/watch?v=oyLBGkS5ICk)

I really enjoy how the package-manager for the Elm programming language automates semantic versioning by diffing your apis based on the type system.

I think a bit part of the real criticism of SEMVER stems from this inability to either automate it or use it correctly.

Hickey's discussion of the subject obviously has a lot more great points to it, and even when I don't agree, I can't help to enjoy listening :)

Re:Top Developer Tools of 2016 on Wednesday January 11, 2017 @03:05PM (#13377049)
"isomorphic javascript"... I thought we had moved past that :(
Re:Principles of Programming Languages (2011) on Sunday December 25, 2016 @04:22AM (#13253533)
Not even a mention of functional programming? Makes me wonder
Re:Offline First – A Better HTML5 User Experience on Friday December 23, 2016 @02:20PM (#13246672)
I feel like commenting on the callbacks and variable-bound-contexts, and saying something about the glorious wonder of modern JavaScripts... better not, tho :)
Re:30-Day Vanilla JavaScript Coding Challenge on Friday December 09, 2016 @04:50AM (#13137767)
Applied tool - Babel?
Re:Show HN: Skov – A visual programming environment on Friday December 02, 2016 @07:30PM (#13093486)
This might be cool for something like Elm? :) maybe even implement it in Elm with something like the Electron project?
Re:Spec-ulation – Rich Hickey [video] on Friday December 02, 2016 @07:18PM (#13093424)
exactly my thought, having dug into GraphQL recently and seen a number of talks about it.

Getting over the annoyance of looking at some initial functionality that is misplaced can be quite hard... It's really tempting to just get rid of those as you're bumping up the MAJOR.

"Nikola" Motors... "Java" Script.
Re:Elm is Wrong on Wednesday November 09, 2016 @08:37AM (#12910111)
Sandy is wrong.
Try the Elm programming language - it should save you the trouble of dealing with the explosion of JavaScript frameworks. It is designed with learning in mind, and should provide a really direct path to high quality front-end code.

http://elm-lang.org/