Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Motivation – Keli Language

keli-language.gitbook.io

Post reply on HN
Print view View original

251–260 of 300 posts

Re: Motivation – Keli Language

#251

Post by munk-a »

mattmanser wrote: post #201
HelloNurse wrote: post #126

Earlier quoted context omitted.

I'd prefer readability to suffer because the fold over a monad needs something clever that requires a bit of reasoning to understand than because vast amounts of "readable" boilerplate (for example, trivial getters and setters) hide a needle in a haystack.

Maybe in the 00s, but these days most languages have collapsed boiler plate down massively. This comes across as an old fashioned view (bordering on extremely old-fashioned).

I haven't seen evidence of reduced getters & setters in my day to day yet - they still seem pretty prevalent when OOP comes into the picture. I'd even say they got a bit worse because now it's excessive getters and setters with gigantic JavaDoc style comments all around them. If I see "@returns id integer The ID" one more time I'll be tempted to throw my monitor out the window.

Re: Motivation – Keli Language

#252

Post by munk-a »

galaxyLogic wrote: post #247
bauerd wrote: post #131

Earlier quoted context omitted.

>The other reason is that many FP users are too enthusiastic about creating abstractions. Elm lacks typeclasses, yet I've found this lack is what keeps a lot of libraries at bay that would have otherwise turned out overly abstract (see any mainstream Haskell library, really). It's the same reasoning behind Go: With great power comes great responsibility. At large, programmers shoot their own feet with powerful langua…

Overuse of abstraction is penny-wise and pound-foolish. It is penny-wise in that it saves some code, but pound-foolish in that it makes maintenance harder. Why? Because when you have an abstraction, your code, possibly in many places, depends on it. Now if you need to make a change, you will need to understand both the abstraction, and your "instance" of it. Well no rather you need to understand ALL instances of that…

I agree with you because you said overuse - but I wanted to reinforce that this is statement reads: "It's a bad idea when it's a bad idea" which isn't super helpful and might give the impression that abstraction is usually the bad option. There are very very few times when I've seen the correct answer between abstracting code and leaving it as-is being leaving it as-is when a good abstraction is possible - but I've also seen a lot of incorrect misaligned abstractions that abstract functionality that coincidentally looks the same (i.e. sharing similar business rules as an origin) but is actually quite different. If you're calculating the final price on a transaction and that item could be either a donut with a 5% food tax or a t-shirt with a 5% sales tax it's not appropriate to abstract taxes to be 5% - they're different taxes and just because they happen to be the same number making them reference the same logic block or constant is a Bad Idea(tm).

Abstraction is (generally) an investment in the long term health of your system, whether you, the dev, can justify the costs to higher ups or not is usually a pretty big part of the question. But, if there are legitimately abstractable things you can abstract please do abstract them (and add tests over everything).

Re: Motivation – Keli Language

#253

Post by a1369209993 »

rstarast wrote: post #151
enricozb wrote: post #5

When giving an example on how infix notation reads better: // This is obviously not too right ",".splitBy("1,2,3,4,5") // This should be right, because it reads out more naturally "1,2,3,4,5".splitBy(",") It's funny that in Python split works this way but join doesn't. This is because in the case of split both arguments are strings, but for join one of the arguments is a Sequence, which is a general protocol rather t…

Hmm, to me it seems that 'splitBy ","' should be a function that takes a string and returns a list of strings: splitBy "," : String -> List String so it seems "clear" that the separator should be the first argument. But maybe I've just programmed functionally for too long? As an alternative, perhaps there's space to introduce types to make this something like split : Pattern -> String -> List String

I don't have a firm position on the matter, but consider:

  lines content = content .splitBy "\n"
  lines = (.splitBy "\n")
  dec x = x - 1
  dec = (- 1)
It seems like some infix-like things ought to be equivalent to (oper right left) rather than (oper left right). Not sure how that works out in practice, though.

Re: Motivation – Keli Language

#254

Post by albertsondev »

dkarl wrote: post #110
misja111 wrote: post #34

I think it's great that Keli is designed with IDE support in mind. However I believe that this is only half of the reason why FP still doesn't really break through in the corporate world. The other reason is that many FP users are too enthusiastic about creating abstractions. This is of course something that FP is exceptionally well suited for. An api that was written to simply process a list of Orders into a Report…

> By the way this problem is not unique for FP, OOP suffered the same problem in the past. But the OOP community learned from its mistakes and now most developers know to 'prefer composition over inheritance', for instance. This is a great point. I think there are a lot of open questions about basic questions such as how ergonomic effect systems can become and which functional programming abstractions become intuitiv…

C#, mostly.

Re: Motivation – Keli Language

#255

Post by galaxyLogic »

munk-a wrote: post #252
galaxyLogic wrote: post #247

Earlier quoted context omitted.

Overuse of abstraction is penny-wise and pound-foolish. It is penny-wise in that it saves some code, but pound-foolish in that it makes maintenance harder. Why? Because when you have an abstraction, your code, possibly in many places, depends on it. Now if you need to make a change, you will need to understand both the abstraction, and your "instance" of it. Well no rather you need to understand ALL instances of that…

I agree with you because you said overuse - but I wanted to reinforce that this is statement reads: "It's a bad idea when it's a bad idea" which isn't super helpful and might give the impression that abstraction is usually the bad option. There are very very few times when I've seen the correct answer between abstracting code and leaving it as-is being leaving it as-is when a good abstraction is possible - but I've a…

> Abstraction is (generally) an investment in the long term health of your system

Don't forget the Opportunity Costs. If you spend much time abstracting, it is less time actually producing something that helps the users of the application.

Now if your business is maintaining an existing application it makes sense you should invest in making its maintenance easier.

But if you are programming a new application you want to get it in production fast, so that you can learn about what needs to be different about it.

I would say that the time to think about maintenance is mostly when you are in the maintenance stage, because of the huge benefit of getting early feedback,

Re: Motivation – Keli Language

#256

Post by grantjpowell »

throwawaw wrote: post #245
grantjpowell wrote: post #143

Earlier quoted context omitted.

Yeah, this exact flow was a pain for me in switching from vscode to vim full time. My flow now is to search for a bunch of instances using the fzf plugin ( https://github.com/junegunn/fzf.vim ) and open them into the quickfix list, then do something like :%s/old/new/gce | :w | :bnext

Is fzf buying you anything over just using :grep? (If speed is the issue, the magic words are `set grepprg='rg --vimgrep'`, after which it's actually usable.)

I've never really explored the native grep functionality, so its possible I'm missing something.

The two features I really like about fzf are

1.) the preview window (visible here https://github.com/junegunn/fzf)

2.) Fuzzy finding/multi-selection/gradual refinement of search terms

Re: Motivation – Keli Language

#257

Post by WillPostForFood »

lostcolony wrote: post #67
WillPostForFood wrote: post #47

Earlier quoted context omitted.

>I absolutely hate named parameters. They’re biased towards new users of a language and quickly become painful to write once you’re familiar with the function call. It is a fair complaint, but don't you think this is offset almost entirely by a good IDE?

First, having spent the past two years in IntelliJ with Java, no. I still would have much preferred named parameters to having to worry about the order (and still occasionally mixing them up when they're not unique types, and only finding out when things fail). Second, if a language is heavily reliant on features from an IDE, yeah, I'll echo that's a badly designed language.

Sorry, I agree with you. I like named parameters as well. I meant the overhead of having to type them is pretty much entirely offset by a good IDE that fills them out for you. I don't think there is a downside unless you are coding in a text editor.

Re: Motivation – Keli Language

#258

Post by jlarocco »

simias wrote: post #147
smithza wrote: post #87

Earlier quoted context omitted.

I don't see a reason why some FP languages (e.g. lisp, or elisp) aren't IDE friendly. It might well be because where there is unpopularity, there is less effort to integrate, promote and maintain. If everything is a function and functions have positional parameters and everything named can be in a symbol table, why can't IDEs support (at least the basics of) FP languages?

I don't know much about modern IDEs because I don't use them, but I suspect that the very powerful lisp macro system can be an issue for good IDE integration. Think of something like the "loop" construct in Common Lisp: http://cl-cookbook.sourceforge.net/loop.html That's related with the problem the parent is talking about: it's very easy to create DSLs in in languages like Common Lisp, so people use them a lot. But…

That's an interesting theory, but not true in practice. Common Lisp IDEs are great and don't have any problems with macros. Even going back to the 70s and 80s, with Lisp machines.

Using Slime, the Common Lisp IDE mode in Emacs, there are at least four ways to answer your loop questions:

1. Ctrl-x, Ctrl-/ to look it up in the Lisp spec

2. Alt-. to jump to the definition

3. Alt-x slime-macro-expand-1 or Alt-x slime-macro-expand-all to see what code the macro generates

4. Execute it in the REPL and see what it does.

Option 1 only works for things defined in the standard, obviously, but options 2-4 work for everything.

Re: Motivation – Keli Language

#259

Post by newen »

dmitriid wrote: post #209
sfvisser wrote: post #13

I really appreciate the effort of designing the syntax to match common IDE expectations. However, I think it shouldn't be too difficult to add intellisense for Haskell-like syntax to IDEs as well. Especially with all the types available! The only unconventional thing is that the function might be put in-front of the value and some parentheses need to be added, instead of just putting it after the cursor like with met…

> I think it shouldn't be too difficult to add intellisense for Haskell-like syntax to IDEs as well. Especially with all the types available! On the contrary, this should give Haskell an advantage because all the types are known and the IDE should be able to autocomplete only the correct parameters. But that requires compiler-as-a-service, and GHC is not. And writing your own analyser for a language is quite a task.

Isn’t that why language server protocol is a thing?

Re: Motivation – Keli Language

#260

Post by throwawaw »

grantjpowell wrote: post #256
throwawaw wrote: post #245

Earlier quoted context omitted.

Is fzf buying you anything over just using :grep? (If speed is the issue, the magic words are `set grepprg='rg --vimgrep'`, after which it's actually usable.)

I've never really explored the native grep functionality, so its possible I'm missing something. The two features I really like about fzf are 1.) the preview window (visible here https://github.com/junegunn/fzf ) 2.) Fuzzy finding/multi-selection/gradual refinement of search terms

Nope, you're not missing anything, then. Maybe I am -- I use the fzf plugin, but only for finding files. Is this (build_quickfix_list) what you're using? https://github.com/junegunn/fzf/blob/master/README-VIM.md#ex...
Post reply on HN